lkml.org 
[lkml]   [1996]   [Jun]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: SCSI device numbering (was: Re: Ideas for v2.1
Date
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.


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.030 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site