Date: Tue, 27 May 2008 22:23:32 +0200 From: Ed Schouten <ed@80386.nl> To: Kostik Belousov <kostikbel@gmail.com> Cc: arch@freebsd.org Subject: Re: Simplifying devfs: minor == unit Message-ID: <20080527202332.GP64397@hoeg.nl> In-Reply-To: <20080527201002.GU21317@deviant.kiev.zoral.com.ua> References: <20080527130615.GJ64397@hoeg.nl> <20080527150244.GN21317@deviant.kiev.zoral.com.ua> <20080527165753.GK64397@hoeg.nl> <20080527191302.GS21317@deviant.kiev.zoral.com.ua> <20080527193242.GN64397@hoeg.nl> <20080527194823.GT21317@deviant.kiev.zoral.com.ua> <20080527194840.GO64397@hoeg.nl> <20080527201002.GU21317@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
--JQ29orswtRjjfiJM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Kostik Belousov <kostikbel@gmail.com> wrote: > On Tue, May 27, 2008 at 09:48:40PM +0200, Ed Schouten wrote: > > * Kostik Belousov <kostikbel@gmail.com> wrote: > > > In fact, I do not understand why you leave the UMINORMASK stuff. It m= akes > > > no sense with the unit =3D=3D minor, IMHO. > >=20 > > 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. >=20 > 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]. >=20 > Also, look at the sys/types.h: >=20 > #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 */ >=20 > #define makedev(x,y) ((dev_t)(((x) << 8) | (y))) /* create dev_t */ >=20 > 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. >=20 > 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. >=20 > It would be nice to verify that the linuxolator emulation still works > (look at the compat/linux/linux_stats.c). Wait. uminor() and umajor() are used on the device number that's returned by dev2udev(). They are only used to obtain the major and minor number from a user device number, which can then be converted to a native Linux/SVR4/etc dev_t. We should not turn this into a 1:1 mapping. The values of dev2unit(cdev) and minor(cdev) should _never_ end up in userspace. It's quite confusing. MAXMINOR currently has a redundant meaning inside the kernel. It is used for both the user major/minor numbers, but also the kernel ones minor numbers (we don't store major numbers there), which is why I renamed it to UMINORMASK while there. --=20 Ed Schouten <ed@80386.nl> WWW: http://80386.nl/ --JQ29orswtRjjfiJM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkg8bcQACgkQ52SDGA2eCwXimgCeJxWBoPUZBObWYWWBLKJOY1rW u5MAnRHhfY0RuSBe0w4t8o3AjksPNjK2 =WAk9 -----END PGP SIGNATURE----- --JQ29orswtRjjfiJM--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080527202332.GP64397>