Messages in this thread |  | | Date | Wed, 26 Jun 1996 15:12:14 +0200 | From | Andries.Brouwer@cwi ... | Subject | Re: SCSI device numbering (was: Re: Ideas for v2.1 |
| |
Stephen Tweedie:
: On Sat, 22 Jun 1996 21:06:39 +0200, Andries.Brouwer@cwi.nl said:
: > Eric Youngdale: : > : .... Clearly a larger : > : dev_t is needed, no matter how we do it. We need to somehow agree on how : > : large this needs to be, and *then* we need to fix the filesystems so that : > : they store a dev_t that is this large.
: > Yes. I think we do not have very much choice: : > POSIX requires dev_t to be an arithmetic type (so it cannot be a struct), : > which on Intel limits us to 64 bits. : > Since changing is slow and painful it seems a bad idea to go to 32 bits : > and have to change again a few years later. : > On the other hand, not many C compilers support long long, so a 64-bit : > dev_t would limit us to gcc. I don't know whether that would be a : > problem for anybody.
: One word of warning --- this will break POSIX. "gcc -ansi : -pedantic-errors" will not compile code with long long declarations. : Any truly, strictly ANSI environment won't be able to compile programs : referencing a 64-bit dev_t.
Yes, but that can be repaired just by changing an include file.
[The implementation I have in mind goes like this: dev_t has 64 bits. If the top 32 are nonzero then we actually have 64 bits, split 16+48, say. If the top 32 are zero, but the following 16 are nonzero, then we actually have 32 bits, split 12+20, say. Otherwise we have 16 bits, split 8+8. (Code somewhat similar to this can already be found in the kernel.) If an include file defines dev_t as short+48 bits of padding, or as int+32 bits of padding, programs will compile in a strict environment, and actually function, except of course that programs compiled that way cannot access devices with large dev_t, and stat() would fail with E2BIG or so, just like stat() will fail on files that are too large (with EFBIG or so).]
Andries
|  |