From: Andries.Brouwer@cwi.nl
To: alan@lxorguk.ukuu.org.uk, sdake@mvista.com
Cc: Joel.Becker@oracle.com, dougg@torque.net, kurt@garloff.de,
linux-kernel@vger.kernel.org
Subject: Re: 32bit dev_t
Date: Fri, 24 Jan 2003 23:04:45 +0100 (MET) [thread overview]
Message-ID: <UTC200301242204.h0OM4jU09451.aeb@smtp.cwi.nl> (raw)
> Who is tracking the 32bit dev_t effort for 2.5?
Once or twice a year I build a kernel with 32bit or 64bit dev_t.
Every now and then submit a few patches so that doing so
remains easy. The last real change was the change in prototype
of the VFS *_mknod functions.
: 32bit dev_t IMHO is essential to 2.6. Essential enough that if its not
: in the base 2.6 all the vendors have to get together and issue a Linus
: incompatible but common 32bit dev_t interface.
The main point to decide would be the external dev_t format.
Of course the format must be compatible with existing filesystems
and binaries. For example,
#define MAJOR(dev) ((unsigned int)(((dev) & 0xffff0000) \
? ((dev) >> 16) & 0xffff : ((dev) >> 8) & 0xff))
#define MINOR(dev) ((unsigned int)(((dev) & 0xffff0000) \
? ((dev) & 0xffff) : ((dev) & 0xff)))
#define MKDEV(ma,mi) ((dev_t)((((ma) & ~0xff) == 0 && ((mi) & ~0xff) == 0) \
? (((ma) << 8) | (mi)) : (((ma) << 16) | (mi))))
This is 1-1 on nonzero majors (and zero major, 8-bit minor).
Once the decision has been made on the size of dev_t and the
computation of major,minor given a dev_t, it is straightforward
to implement that decision. Unfortunately not only the kernel
but also glibc must be changed.
In glibc one needs to fix in sysdeps/unix/sysv/linux
the files sys/sysmacros.h, bits/stat.h, ustat.c, xmknod.c.
In the kernel there are lots of tiny fixes needed because
people did not distinguish between int and dev_t and kdev_t.
Nothing major.
(Anyone can boot a 2.5 kernel with 32-bit dev_t by changing
include/asm-i386/posix_types.h
(change the line "typedef unsigned short __kernel_dev_t;"
to what is desired, e.g. s/short/int/) and changing
include/linux/kdev_t.h
(change the typedef for kdev_t to have e.g. unsigned int,
set KDEV_MINOR_BITS and KDEV_MAJOR_BITS to 16,
change the 0xff in the definition of major and minor to 0xffff,
change the definitions of MAJOR, MINOR, MKDEV as above).)
[Warning: I do such things and it works. But if you do so,
it may well destroy your filesystems. A complete patch has
minor fixes all over the place.]
Andries
next reply other threads:[~2003-01-24 21:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-24 22:04 Andries.Brouwer [this message]
2003-01-25 1:51 ` Joel Becker
2003-02-03 18:21 ` H. Peter Anvin
-- strict thread matches above, loose matches on Subject: below --
2003-01-21 19:50 Joel Becker
2003-01-21 21:29 ` Steven Dake
2003-01-21 21:56 ` Joel Becker
2003-01-21 22:21 ` Jeff Garzik
2003-01-21 22:33 ` Alan
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=UTC200301242204.h0OM4jU09451.aeb@smtp.cwi.nl \
--to=andries.brouwer@cwi.nl \
--cc=Joel.Becker@oracle.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=dougg@torque.net \
--cc=kurt@garloff.de \
--cc=linux-kernel@vger.kernel.org \
--cc=sdake@mvista.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®