> On Thu, 15 Jan 1998, Chris G. Demetriou wrote:
> 
> : [ I've been busy with other things the last few days. ]
> 
> And in that time you missed an important point on this track.  :)

No, I don't think I have.


> : > `Yeah, right.'  Past experience shows that any time you expect users
> : > to do two things at once, some of them are going to forget, not read
> : > the directions at all, or just plain screw it up.  Why have the
> : > support hassle when you don't need it?
> : 
> : I, for one, would rather take the support hassle once or twice --
> : i.e. when the switch is made in -current and when the next release is
> : done (and the latter shouldn't be a hassle, if the upgrade process is
> : any good) -- than be saddled with a bad-looking device number format
> : for years to come.
> 
> The thing is, this matter is fine now.  Taking a suggestion from you (table
> of major numbers/minor-number-translating functions) and Charles's
> suggestions wrt specinfo, it's now possible to have both 16 and 32 bit
> dev_t's coexisting.  Translation is only done when the kernel caches the
> dev_t deep in a vnode (used when calling device functions), and the devices
> see 32 bit dev_t's whereas userland sees untouched dev_t's.  Voila!

He was talking about about updating MAKEDEV and mknod at the same
time.

Are you saying that you can run an old MAKEDEV with a new mknod now?
I don't think i've ever seen you indicate that.


I don't think it's necessary to worry about that.  Changes of that
general nature happen quite often in this project (most notably,
"build and install a new kernel before you build and install a new
libc!!!"), and don't pose any 'special' challenge to users.

Users who are running -current know the pitfalls, and an announcement
to the current-users list should be (but hardly ever is 8-) sufficient
to get them to do the right things.

Users doing binary upgrades between releases should have the work
taken care of for them by the upgrade script.



cgd