> Im very interested in 32bit dev_t or at least implementing
> the 'lots of majors' half of it because we are probably
> going to need it in the 2.5 years before we have a 2.6
Yes, a larger dev_t has been desirable for a long time,
and more and more kludges are invented to work around its lack.
S
> Hmm. You make me search for this old patch.
> Since Linus' reaction was not exactly positive I left
> the topic again, but there must be a copy somewhere..
Given current real world evolution Im very interested in 32bit dev_t or at
least implementing the 'lots of majors' half of it because we ar
>> The exercise is essentially the patch that I sent last month or so.
> mknod takes a 32bit input
> the stat64 padding only has room for 32bits
Hmm. You make me search for this old patch.
Since Linus' reaction was not exactly positive I left
the topic again, but there must be a copy somewhere..
On Mon, May 14, 2001 at 03:57:21PM +0100, Alan Cox wrote:
> > > 20:12 is more common
> >
> > Which is major, which is minor?
>
> 20bit major
Well, AIX 4.3 (and 4.[12] I think as well) uses 16:16, and they
are preparing for 32:32 when the kernel finaly goes fully 64-bit. I
don't know en
> The fs and stat structs are set up to allow 32bits.
> 64bits is a major exercise
No. Inside the kernel the dev_t type does not really occur.
The exercise is essentially the patch that I sent last month or so.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> No. Inside the kernel the dev_t type does not really occur.
> The exercise is essentially the patch that I sent last month or so.
mknod takes a 32bit input
the stat64 padding only has room for 32bits
The kernel representation internally I dont care about, its probably a pointer
not a 32:32 tho
> That is not more common. Around us we see major:minor splits
> 8:24, 12:20, 14:18. If we want to use NFSv3 and communicate
> with all these systems we would do wise to use 32:32.
My error. 32:32 is however not interesting. The fs and stat structs
are set up to allow 32bits. 64bits is a major ex
>>> 20:12 is more common
>> Which is major, which is minor?
> 20bit major
That is not more common. Around us we see major:minor splits
8:24, 12:20, 14:18. If we want to use NFSv3 and communicate
with all these systems we would do wise to use 32:32.
[Reminds me of a discussion that ended unfini
Followup to: <[EMAIL PROTECTED]>
By author:Alan Cox <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> > > 20:12 is more common
> >
> > Which is major, which is minor?
>
> 20bit major
>
Surely you're jesting?
12 bit major, 20 bit minor is the only logical split. The need for
minors
> > 20:12 is more common
>
> Which is major, which is minor?
20bit major
> I have one (private) driver that requires around 5000 minors.
> (currently through some 20 majors) (Currently only just over half of
> these are physically installed)
Just use several. The split is a bit vague in mo
Alan Cox wrote:
> > 255. Has this limitation been some how addressed with 2.4? 256 devices
> > per module, sometimes is not enough, especially if you are in the SAN
> > environment; or when the 256 minors numbers are broken down to several
>
> 2.4 is using 16bit dev_t in kernel still. Applicati
> 255. Has this limitation been some how addressed with 2.4? 256 devices
> per module, sometimes is not enough, especially if you are in the SAN
> environment; or when the 256 minors numbers are broken down to several
2.4 is using 16bit dev_t in kernel still. Application space sees a much
large
12 matches
Mail list logo
