From: Andries.Brouwer@cwi.nl
To: Andries.Brouwer@cwi.nl, akpm@digeo.com
Cc: Joel.Becker@oracle.com, andrey@eccentric.mae.cornell.edu,
linux-kernel@vger.kernel.org, torvalds@transmeta.com
Subject: Re: major/minor split
Date: Wed, 19 Mar 2003 22:40:15 +0100 (MET) [thread overview]
Message-ID: <UTC200303192140.h2JLeF924104.aeb@smtp.cwi.nl> (raw)
> Shouldn't this be "typedef unsigned int __kernel_dev_t;" ?
This is for you to play with, not a submitted patch.
Make it int, long, long long - whatever you like.
> This is 16+16. What is involved in going to 12+20?
Editing kdev_t.h and changing one 16 to 12 and another 16 to 20.
And then there are two 0xffff, lazy as I am, that you would
have to turn into the appropriate masks: e.g., for 13+19:
#define KDEV_MINOR_BITS 19
#define KDEV_MINOR_MASK ((1<<KDEV_MINOR_BITS) - 1)
#define KDEV_MAJOR_BITS 13
#define KDEV_MAJOR_MASK ((1<<KDEV_MAJOR_BITS) - 1)
#define minor(dev) ((dev).value & KDEV_MINOR_MASK)
#define major(dev) (((dev).value >> KDEV_MINOR_BITS) & KDEV_MAJOR_MASK)
Similar in the definition of MAJOR and MINOR.
One of these weeks I'll give you a better parametrized version.
(I hope the purpose of distinguishing arithmetic types dev_t
and kdev_t is clear. The latter is simple e.g. 13+19.
mk_kdev, major, minor are simple macros. Kernel use is fast,
no conditional involved.
The former must be backwards compatible, so MKDEV, MAJOR, MINOR
are somewhat complicated macros; for example MAJOR asks: does it fit
in 16 bits? then MAJOR is the first 8; otherwise MAJOR is
the first DEV_MAJOR_BITS. Used only when converting from userspace.)
> What glibc changes are required?
Glibc has:
int
xmknod (int vers, const char *path, mode_t mode, dev_t *dev) {
unsigned short int k_dev;
k_dev = ((major (*dev) & 0xff) << 8) | (minor (*dev) & 0xff);
return INLINE_SYSCALL (mknod, 3, CHECK_STRING (path), mode, k_dev);
}
You see that even though glibc dev_t is very large, the peephole
offered with mknod is tiny. So, the glibc mknod routine must be fixed.
Also the macros major, minor, makedev in <sys/sysmacros.h>.
> What happens with an old glibc?
As long as you do not use new device numbers, all is well.
With new device numbers and an old glibc, major and minor
will be truncated to 8 bits in many places.
So, anybody who wants to use 10000 disks will also have to
use the latest glibc.
Andries
next reply other threads:[~2003-03-19 21:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-19 21:40 Andries.Brouwer [this message]
2003-03-20 21:00 ` Roman Zippel
2003-03-20 21:47 ` Joel Becker
2003-03-20 22:03 ` Joel Becker
2003-03-20 22:24 Andries.Brouwer
2003-03-20 23:23 ` Roman Zippel
2003-03-21 0:04 ` H. Peter Anvin
2003-03-20 23:52 ` H. Peter Anvin
2003-03-21 7:35 Andries.Brouwer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=UTC200303192140.h2JLeF924104.aeb@smtp.cwi.nl \
--to=andries.brouwer@cwi.nl \
--cc=Joel.Becker@oracle.com \
--cc=akpm@digeo.com \
--cc=andrey@eccentric.mae.cornell.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®