Simplifying devfs: minor == unit

Kostik Belousov kostikbel at gmail.com
Tue May 27 20:10:23 UTC 2008


On Tue, May 27, 2008 at 09:48:40PM +0200, Ed Schouten wrote:
> * Kostik Belousov <kostikbel at gmail.com> wrote:
> > In fact, I do not understand why you leave the UMINORMASK stuff. It makes
> > no sense with the unit == minor, IMHO.
> 
> That's because the uminor() and umajor() routines operate on user device
> numbers (dev_t's). We need to leave those intact, to make things like
> the binary compat work.

What does it mean to take bits 8-15 from the the unit number to denote
some fictitious major ? And, what binary compatibility you talk about
? You changed the layout of the encoding for the minor, but still take
the major from it, while there is simply no space for major after your
patch, and definitely not in [8:15].

Also, look at the sys/types.h:

#ifndef _KERNEL
/*
* minor() gives a cookie instead of an index since we don't want to
* change the meanings of bits 0-15 or waste time and space shifting
* bits 16-31 for devices that don't use them.
*/
#define major(x)        ((int)(((u_int)(x) >> 8)&0xff)) /* major number */
#define minor(x)        ((int)((x)&0xffff00ff))         /* minor number */
#endif /* !_KERNEL */

#define makedev(x,y)    ((dev_t)(((x) << 8) | (y)))     /* create dev_t */

I think, if you want to do the change you proposed, the minors for cdevs
shall be cleanly separated from the major/minor something, the later has no
relations with the cdevs in the current FreeBSD.

I.e., in your patch, the uminor() can and shall be made identity
function, to match minor2unit() and unit2minor(), and umajor() shall just
return 0.

It would be nice to verify that the linuxolator emulation still works
(look at the compat/linux/linux_stats.c).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20080527/a410a5eb/attachment.pgp


More information about the freebsd-arch mailing list