On Fri, 16 Jan 1998, Eduardo E. Horvath wrote:

> I hate to get involved in this flame fest but there are a few points that
> neither side of this argument seems to have stumbled across yet.

I think you kept things flame free. If we screw up the transition to
32-bit devices, then we really loose. We DO need to think this through.

> On Fri, 16 Jan 1998, Todd Vierling wrote:
> 
> > Okay, people are saying I'm missing some points; people are saying Charles
> > is missing some points.  I'll weigh what I can see as advantages and
> > disadvantages of both procedures.  Please, if I've missed something here,
> > tell me and I will add it to the list and repost, but I'm not into the
> > mudslinging, so please send flame to /dev/null.
> > 
> > Contiguous bits for major and minor - Advantages:
> > - Cleaner coded, and becomes only a slight modification of the 16-bit system
> >   if compatibility drops out
> > - Can use a completely merged devsw as translation is done before use of
> >   a dev_t in the kernel
> > - It has overwhelming precedent
> > 
> > Disadvantages:
> > - Requires MAKEDEV and mknod(8) be updated at the same time, or that MAKEDEV
> >   be updated to use new mknod(8) flags before the change

Todd, NO! Whatever we do, the old mknod semantics need to generate old
nodes.

> This can be mitigated by reserving the first 256 32-bit major numbers for
> compatibility devices.  mknod creates a 16-bit node for majors < 256 and
> 32-bit nodes for majors beyond 256.  Yes, this is ugly and creates a hole
> in the device table, but splitting the minor does exactly the same thing.
> And eventually this hole can be reassigned when COMPAT_DEV_13 goes away.

I agree. Let's just, for now, make the first 256 devices 16-bit. Then
there's no problem.

> That way an old MAKEDEV with a new mknod works fine, and I should hope
> that the old mknod with an invalid major (new MAKEDEV) should bomb.  If it
> does not bomb you have a 16-bit node with truncated major and minor
> numbers.  You would have the same problem if you split the minor.

I actually read the source (what a concept!) and mknod just hands the
numbers it gets to the mknod system call. So if we choose "current"
major numbers to be "16-bit" numbers, all we need to do is have the mknod
syscall make "16-bit" nodes for those majors (if major < 100 or 256 as we
choose).

mknod actually won't have to change at all. We just have to make the mknod
syscall DTRT.

> > 
> > Advantage or disadvantage, depending on the user:
> > - ls(1) displays old device nodes with a major number of zero, the
> >   reserved compatibility number
> 
> I would hope ls(1) had compatibility code to properly print 16-bit
> dev_t's.

I agree. We could even just stick it in the userland major macros.

> > - Requires a separate kernel option to enable compatibility, so prompts
> >   users of -current to ask why a kernel doesn't boot (and receive the answer
> >   of updating mknod(8) and MAKEDEV, then adding appropriate kernel option)

Or we could make it a kernel option to DISABLE compatability. :-)

> > - Forces us to renumber devices now and make the new numbers correspond
> >   between 
> > - A user who MAKEDEV's some 32 bit devices and falls back will be confused
> >   as to why functionality was lost; requires MAKEDEV to have a 16-bit option
> >   or default to such so devices get old node numbers

Once you upgrade devices, I don't think you can fall back. As Chris said,
you can't roll back syscalls in libc's, etc...

> > Neutral (usually "don't care"s):
> > - Makes the dev_t easier to read in a debugging dump of function arguments,
> >   or in a raw hexdump of a filesystem
> > 
> > Optional:
> > - MAKEDEV, when modified, could default to creating 16 bit nodes with the
> >   new mknod(8) (and the options of nmajorbits and nminorbits), allowing
> >   the 32 bit representations to change before 1.4 for new functionality

The nmajorbits stuff got trimmed. But to do that stuff, we'll have to add
a new system call. mknod(8) just calls mknod(2)...

> > =====
> > 
> > Splitting minor into two parts - Advantages:
> > - Works on old or new MAKEDEV and mknod(8), even in different mixes
> > 
> > Disadvantages:
> > - Does not allow for a merged, renumbered device switch table; device
> >   numbers below the predefined N split of `old' and `new' are block/char
> >   dependent (as well as arch dependent)
> > - If compatibility left out, the remnants still exist (five operations for
> >   minor number to be stripped from a dev_t, and a table of N*2 null devices)
> 
> What happens when an old, 16-bit kernel reads a new 32-bit device node?
> If it silently ignores the high bits then you take the chance that your
> new 32-bit device node will match and old 16-bit device and in this case
> you get silent data corruption.  

As mentioned, I think BOTH loose here.

> > Advantage or disadvantage, depending on the user:
> > - ls(1) displays old and new device nodes in the same format
> > - The translation heuristic might be conditional on whether or not a device
> >   is renumbered, prompting an extra conditional translation layer
> > - A user who MAKEDEV's some 32 bit devices and falls back will be confused
> >   as to why functionality was lost; requires MAKEDEV to have a 16-bit option
> >   or default to such so devices get old node numbers
> 
> [...]
> 
> So far I have not seen either side come up with a solution to the problem
> of an old kernel trying to decypher a new device node.  Maybe there is
> none.

I don't think there is. :-(

Take care,

Bill