Messages in this thread |  | | From | Albert Cahalan <> | Subject | Re: SCSI device numbering (was: Re: Ideas for v2.1 | Date | Thu, 27 Jun 1996 19:34:09 -0400 (EDT) |
| |
From: "Stephen C. Tweedie" <sct@dcs.ed.ac.uk>
>>>> POSIX requires dev_t to be an arithmetic type >>>> (so it cannot be a struct),
>>> 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.
> No, not easily. "gcc -ansi -pedantic-errors" will NOT give you > any way of declaring a 64-bit arithmetic type on Intel.
>> [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,
> What do you mean by padding? dev_t cannot include padding fields, > as it must be an arithmetic type. It can't necessarily include > padding bits, due to the ansi compiler 32-bit limit.
Meaning either:
dev_t is 64-bit, but only 48 bits are ever used. The kernel splits it up as junk:major:minor and complains if junk != 0.
Or:
Various structs are declared using "long long" inside of #ifndef. Pure ANSI code gets a substitute struct with the same alignment, a small dev_t, and padding next to the small dev_t. Most programs will work just fine with the fake struct. Just don't compile tar or cpio that way because then your backups of /dev are useless.
>> 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).]
Hmmm, the second meaning I think.
> Now, if we were to create entirely separate environments in libc for > 16, 32 or 64 bit dev_t's, this would work. I really do think it's > just a little bit untidy, though... :) [Having said that, it's quite > similar to what I'll have to do anyway to get the 64bit file api > working.]
There is already room for a 32-bit dev_t in the existing structs.
|  |