> It's not so much about hardcoding the names as hardcoding the *STRUCTURE*
> of the names. For example, the current devfs has /dev/misc/* which is
> completely bogus -- it exposes an implementation detail (using the
The fact kernel space touches on naming directly is itself bogus. devfsd doing
On Mon, 14 May 2001, Alan Cox wrote:
> Abstract device file systems are beautiful concepts but they don't solve
> the device name space problem and they introduce hideous incompatibilities
> with existing software.
let me get it straight. You are talking about software that would be
a
On Monday May 14, [EMAIL PROTECTED] wrote:
> > This means that we need some analogue to {get,put}_unnamed_dev that
> > manages a range of dynamically allocated majors.
> > Is there such a beast already, or does someone need to write it?
> > What range(s) should be used for block devices?
> >
> >
On Monday May 14, [EMAIL PROTECTED] wrote:
> Neil Brown wrote:
> > So I need a major number - to give to devfs_register_blkdev at least.
> > You don't want me to have a hardcoded one (which is fine) so I need a
> > dynamically allocated one - yes?
> >
> > This means that we need some analogue to
> I've been doubting whether to work on both the -ac kernels
> and the -linus tree, but this is a pretty good argument for
> sticking with -ac and just ignoring the -linus tree...
Time will make that decision. Linus kindly gave us all the power to vote with
our feet. One thing I absolutely refuse
Neil Brown wrote:
> So I need a major number - to give to devfs_register_blkdev at least.
> You don't want me to have a hardcoded one (which is fine) so I need a
> dynamically allocated one - yes?
>
> This means that we need some analogue to {get,put}_unnamed_dev that
> manages a range of dynamic
> This means that we need some analogue to {get,put}_unnamed_dev that
> manages a range of dynamically allocated majors.
> Is there such a beast already, or does someone need to write it?
> What range(s) should be used for block devices?
>
> Am I missing something obvious here?
Obvious question
> Big device numbers are _not_ a solution. I will accept a 32-bit one, but
> no more, and I will _not_ accept a "manage by hand" approach any more. The
> time has long since come to say "No". Which I've done. If you can't make
> it manage the thing automatically with a script, you won't get a hard
> Note also that persistence of permissions and hardcoded in-kernel naming
> is a problem throughout proc... It's not unique to in-driver
> filesystems.
And the /proc namespace is a walking testimony to why numbers are not the
primarily problem in /dev space and tidyness
-
To unsubscribe from t
On Mon, 14 May 2001, Linus Torvalds wrote:
> End of discussion.
I've been doubting whether to work on both the -ac kernels
and the -linus tree, but this is a pretty good argument for
sticking with -ac and just ignoring the -linus tree...
Lets see what happens...
regards,
Rik
--
Linux MM bugzi
On Mon, May 14, 2001 at 01:29:51PM -0700, Linus Torvalds wrote:
> Big device numbers are _not_ a solution. I will accept a 32-bit one, but
> no more, and I will _not_ accept a "manage by hand" approach any more. The
> time has long since come to say "No". Which I've done. If you can't make
> it ma
On Monday May 14, [EMAIL PROTECTED] wrote:
>
> End of discussion.
>
> Linus
>
...and start of education please...
I want to create a new block device - it is a different interface to
the software-raid code that allows the arrays to be partitioned using
normal partition tables.
On Mon, 14 May 2001, Jeff Garzik wrote:
>
> Note also that persistence of permissions and hardcoded in-kernel naming
> is a problem throughout proc... It's not unique to in-driver
> filesystems.
Also note how a 32-bit (or 64-bit) dev_t does NOT make it any easier to
manage permissions or anyth
Jeff Garzik wrote:
>
> Note also that persistence of permissions and hardcoded in-kernel naming
> is a problem throughout proc... It's not unique to in-driver
> filesystems.
>
It's not so much about hardcoding the names as hardcoding the *STRUCTURE*
of the names. For example, the current devfs
Note also that persistence of permissions and hardcoded in-kernel naming
is a problem throughout proc... It's not unique to in-driver
filesystems.
--
Jeff Garzik | Game called on account of naked chick
Building 1024|
MandrakeSoft |
-
To unsubscribe from this list: send the line "uns
Richard Gooch wrote:
> So we add yet another series of hacks to avoid doing what's
> necessary?!?
We cannot change the world in a day. :)
"Doing what's necessary" is way beyond the scope of 2.4, IMHO.
--
Jeff Garzik | Game called on account of naked chick
Building 1024|
MandrakeSoft
> > (c) does not require devfs. most distros ship without it afaik, and
> > switching to it is not an overnight process, and requires devfsd to be
> > useful in the real world.
> >
>
> It does, however, not manage permissions, nor does it provide for a sane
> namespace (it exposes too many inte
"H. Peter Anvin" wrote:
> Jeff Garzik wrote:
> > Register block device using existing API, and obtain a dynamically
> > assigned major number. Export a tiny ramfs which lists all device
> > nodes. Mounted on /dev/snap, /dev/snap/0 would be the first blkdev for
> > snap's dynamically assigned maj
Jeff Garzik writes:
> "H. Peter Anvin" wrote:
> > Linus Torvalds has requested a moratorium on new device number
> > assignments. His hope is that a new and better method for device space
> > handing will emerge as a result.
>
> Here's my suggestion for a solution.
>
> Once I work through a bunc
Jeff Garzik wrote:
>
> "H. Peter Anvin" wrote:
> > Linus Torvalds has requested a moratorium on new device number
> > assignments. His hope is that a new and better method for device space
> > handing will emerge as a result.
>
> Here's my suggestion for a solution.
>
> Once I work through a bu
"H. Peter Anvin" wrote:
> Linus Torvalds has requested a moratorium on new device number
> assignments. His hope is that a new and better method for device space
> handing will emerge as a result.
Here's my suggestion for a solution.
Once I work through a bunch of net driver problems, I want to
301 - 321 of 321 matches
Mail list logo
