According to James Simmons:
Graphics cards are the same way. Especially high end ones. They have pipes
as well. For low end cards you can think of them as single pipeline cards
with one pipe.
It still frosts my shorts that DRM (e.g. /dev/dri/card0) doesn't use
write(). It's a natural way to
According to Johannes Erdfelt:
I had always made the assumption that sockets were created because you
couldn't easily map IPv4 semantics onto filesystems. It's unreasonable
to have a file for every possible IP address/port you can communicate
with.
I think you're right on both counts, but
Chip Salzenberg wrote:
According to H. Peter Anvin:
A device can inherently belong to multiple device classes, and it
really should be thought of as such.
And then there are layering technologies like LVM and loopback.
They should be included in a discovery, but if you limit yourself
According to H. Peter Anvin:
A device can inherently belong to multiple device classes, and it
really should be thought of as such.
And then there are layering technologies like LVM and loopback.
They should be included in a discovery, but if you limit yourself
to one device type, there's no
On 15 May 2001 13:26:58 -0700, Dan Hollis wrote:
This thread is becoming high enough volume and likely to become much more
so, perhaps a separate ml should be set up for it? linux-device-management
perhaps?
I agree that this is going to be a very high-volume discussion. OTOH,
this discussion
I couldn't agree with you more. It gives me headaches at work. One note,
their is a except to the eth0 thing. USB to USB networking. It uses usb0,
etc. I personally which they use eth0.
The packet framing is quite different so it doesnt really make sense. For
wireless it does use ethernet
if (strcmp (buffer + len - 2, cd) != 0) {
fprintf (stderr, Not a CD-ROM! Bugger off.\n);
exit (1);
And on my box cd is the cabbage dicer whoops
Actually, no, because it's guaranteed that a trailing /cd is a
CD-ROM. That's the standard.
And its back to
Alan Cox wrote:
Wouldn't it be better just to *try* ioctls and see which ones work and
which ones don't?
1. We have overlaps
1. is of course a problem in itself. Someone who creates overlapping
ioctls should be spanked, hard.
2. I've seen code where people play clever ioctl tricks
Wouldn't it be better just to *try* ioctls and see which ones work and
which ones don't?
1. We have overlaps
2. I've seen code where people play clever ioctl tricks to deduce a device
type and it ends up looking like one of those chemistry identification
charts (hopefully minus do you see
Type of filesystem where the file came from? Sure.
Who says it comes from only one - even on devfs that is not true
/dev/disk/4 is quite possibly
disk
scsi-disk
scsi-device
usb-scsi-device
usb-device
all at once
-
To unsubscribe from this list: send
Alexander Viro writes:
On Tue, 15 May 2001, Richard Gooch wrote:
Alan Cox writes:
len = readlink (/proc/self/3, buffer, buflen);
if (strcmp (buffer + len - 2, cd) != 0) {
fprintf (stderr, Not a CD-ROM! Bugger off.\n);
exit
And my opinion is that the hot-plugged approach works for devices even
if they are soldered down ...
Yep. Though I tend to look at the whole problem as autoconfiguration
lately. Solving device naming (even the major/minor subproblem) is only
one part of having a complete autoconfiguration
Alan Cox writes:
if (strcmp (buffer + len - 2, cd) != 0) {
fprintf (stderr, Not a CD-ROM! Bugger off.\n);
exit (1);
And on my box cd is the cabbage dicer whoops
Actually, no, because it's guaranteed that a trailing /cd is a
CD-ROM.
Richard Gooch wrote:
Alexander Viro writes:
On Tue, 15 May 2001, Richard Gooch wrote:
Alan Cox writes:
len = readlink (/proc/self/3, buffer, buflen);
if (strcmp (buffer + len - 2, cd) != 0) {
fprintf (stderr, Not a CD-ROM! Bugger
1. is of course a problem in itself. Someone who creates overlapping
ioctls should be spanked, hard.
No argument there. But there is no LANANA ioctl body
Agreed, but determining type of device and determining if interface X
is available on this device are different operations. If the
Richard Gooch wrote:
Even if we have per-device filesystems, we are going to have the same
issue, in one form or another. If we have a /devicetype trailing
component added on, then somewhere it has to report CD-ROM or cd
or Compact Disc.
Again, many device types aren't mutually
Keep it informational. And NEVER EVER make it part of the design.
What about:
1 (network domain). I have two network interfaces that I connect to
two different network segments, eth0 eth1;
So?
Informational. You can always ask what eth0 and eth1 are.
[...]
The location of
Even if we have per-device filesystems, we are going to have the same
issue, in one form or another. If we have a /devicetype trailing
component added on, then somewhere it has to report CD-ROM or cd
or Compact Disc.
When I ask it. Not when I name it
-
To unsubscribe from this list: send the
On Tue, 15 May 2001, Richard Gooch wrote:
MeLinus. The device name authority (Peter). Whoever. If you want
Peter to bless it, then fine. But the standard is there. Violators
will be persecuted.
Ah, standard on names in devfs? About as relevant as GOSIP...
-
To unsubscribe from this list:
Alan Cox wrote:
1. is of course a problem in itself. Someone who creates overlapping
ioctls should be spanked, hard.
No argument there. But there is no LANANA ioctl body
I though Michael Chastain was maintaining this set. No, we haven't made
it an official LANANA function, mostly
Alex Bligh writes:
Q: Let us assume you have dynamic numbering disk0..N as you suggest,
and you have some s/w RAID of SCSI disks. A disk fails, and is (hot)
removed. Life continues. You reboot the machine. Disks are now numbered
disk0..(N-1). If the RAID config specifies using
I couldn't agree with you more. It gives me headaches at work. One note,
their is a except to the eth0 thing. USB to USB networking. It uses usb0,
etc. I personally which they use eth0.
USB to USB networking cables aren't ethernet.
I'm talking about a wireless connection. ipaq
According to Alan Cox:
Given a file handle 'X' how do I find out what ioctl groups I should
apply to it.
Wouldn't it be better just to *try* ioctls and see which ones work and
which ones don't?
You can do this with the tty layer. Just open /dev/tty and try tioclinux.
On my serial
Graphics cards are the same way. Especially high end ones. They have pipes
as well. For low end cards you can think of them as single pipeline cards
with one pipe.
It still frosts my shorts that DRM (e.g. /dev/dri/card0) doesn't use
write(). It's a natural way to feed pipelines. But
David Bronwell writes:
Linus writes:
Now, if we just fundamentally try to think about any device as being
hot-pluggable, you realize that things like which PCI slot is this device
in are completely _worthless_ as device identification, because they
fundamentally take the wrong
Chip Salzenberg wrote:
According to Alan Cox:
Given a file handle 'X' how do I find out what ioctl groups I should
apply to it.
Wouldn't it be better just to *try* ioctls and see which ones work and
which ones don't?
As ioctl's is just numbers that can be valid but mean totally
The eth0..N naming is done RIGHT!
Only if it's augmented by additional device IDs, such as the
what 's the physical connection for this interface sort of
primitive that's been mentioned.
Nothing to do with the kernel but, one should then argue that the
current stuff in
On Tue, 15 May 2001, David Brownell wrote:
I suppose that for network interface names, some convention for
interface ioctls would suffice to solve that identify step. PCI
devices would return the slot_name, USB devices need something
like a patch I posted to linux-usb-devel a few months
[ Re why physical device IDs _should_ have a critical role in sysadmin ]
I would have to agree that stable is critical to not driving people
crazy. In the case of AIX, once a device is enumerated, it will retain
the same name across reboots. Enough information is kept about each
device to
According to Alan Cox:
Chip:
Wouldn't it be better just to *try* ioctls and see which ones work and
which ones don't?
1. We have overlaps
We all agree that overlaps need to be eliminated over time. In the
meantime, as a coping strategy: I'll bet you that for any two given
device
OK, just correct me if I get this wrong, but this code is taking the LAST 2
characters of the device name and verifying that it is cd. Which would
mean that the standard states that /dev/ginsucd would be a CD-ROM drive?
That is why I feel a name of a device handle shouldnt set how a driver
On Wednesday 16 May 2001 01:16, David Brownell wrote:
Only if it's augmented by additional device IDs, such as the
what 's the physical connection for this interface sort of
primitive that's been mentioned.
[...]
I suppose that for network interface names, some convention for
interface ioctls
, May 15, 2001 11:30 AM
To: Linus Torvalds; Jonathan Lundell
Cc: Jeff Garzik; James Simmons; Alan Cox; Neil Brown; H. Peter Anvin;
Linux Kernel Mailing List; [EMAIL PROTECTED]; Alex Bligh - linux-kernel
Subject: Re: LANANA: To Pending Device Number Registrants
The argument that if you use numbering
I suppose that for network interface names, some convention for
interface ioctls would suffice to solve that identify step. PCI
devices would return the slot_name, USB devices need something
like a patch I posted to linux-usb-devel a few months back.
This is crap.
Only the ioctl
At 4:35 PM -0700 2001-05-15, David Brownell wrote:
[ Re why physical device IDs _should_ have a critical role in sysadmin ]
I would have to agree that stable is critical to not driving people
crazy. In the case of AIX, once a device is enumerated, it will retain
the same name across
On 16 May 2001 01:56:23 +0200, Tim Jansen wrote:
On Wednesday 16 May 2001 01:16, David Brownell wrote:
Only if it's augmented by additional device IDs, such as the
what 's the physical connection for this interface sort of
primitive that's been mentioned.
[...]
I suppose that for network
At 1:18 PM -0700 2001-05-15, Linus Torvalds wrote:
1 (network domain). I have two network interfaces that I connect to
two different network segments, eth0 eth1;
So?
Informational. You can always ask what eth0 and eth1 are.
There's another side to this: repeatability. A setup should be
On Tuesday 15 May 2001 23:20, Nicolas Pitre wrote:
Personally, I'd really like to see /dev/ttyS0 be the first detected
serial port on a system, /dev/ttyS1 the second, etc.
There are well-defined rules for the first four on PC's. The ttySx
better match the labels the OEM put on the box.
--
On Tuesday 15 May 2001 22:51, Linus Torvalds wrote:
On Tue, 15 May 2001, Alexander Viro wrote:
If you want them all to inherit it - inherit from mountpoint.
..which is exactly what the device node ends up being. The implicit
mount-point.
And which point, btw, it is completely
On Tuesday 15 May 2001 17:34, Linus Torvalds wrote:
On Tue, 15 May 2001, Neil Brown wrote:
Ofcourse setting the queue function that __blk_get_queue call to
do a lookup of the minor and choose an appropriate queue for the
real device wont work as you need to munge bh-b_rdev too.
What I
Daniel Phillips wrote:
Sounds like treat it like a file and it acts like a file, treat it
like a directory and it acts like a directory.
The original plan was that you only could indirect through it; not
chdir() for example. One could do the whole enchilada, but then one
would have to
On Wed, 16 May 2001, Daniel Phillips wrote:
On Tuesday 15 May 2001 23:20, Nicolas Pitre wrote:
Personally, I'd really like to see /dev/ttyS0 be the first detected
serial port on a system, /dev/ttyS1 the second, etc.
There are well-defined rules for the first four on PC's. The ttySx
At 9:34 PM -0400 2001-05-15, Nicolas Pitre wrote:
On Wed, 16 May 2001, Daniel Phillips wrote:
On Tuesday 15 May 2001 23:20, Nicolas Pitre wrote:
Personally, I'd really like to see /dev/ttyS0 be the first detected
serial port on a system, /dev/ttyS1 the second, etc.
There are
Jonathan Lundell wrote:
...
I *like* eth0..n (I'd like net0..n better). And I *can't* ask what
eth0 and eth1 are, by the way, but I should be able to (Jeff Garzik
has proposed an extension to ethtool to help out this lack, but it's
not in Linux today, and needs concrete implementation
On Tuesday May 15, [EMAIL PROTECTED] wrote:
On Tue, 15 May 2001, Neil Brown wrote:
Ofcourse setting the queue function that __blk_get_queue call to do
a lookup of the minor and choose an appropriate queue for the real
device wont work as you need to munge bh-b_rdev too.
What I
Miles Lane [EMAIL PROTECTED] wrote on 15/5/01 17:41:
Does your approach solve
the problem of USB devices,
like mice, that
don't have device ID's of any
sort, where topology is the
only way to
distinguish them?
yes, that's what the location part is for.
Bye...
-
To unsubscribe from this
Oliver Neukum wrote:
> >
> > That's not the issue. LILO takes whatever you pass to root= and converts
> > it to a device number at /sbin/lilo time. An idiotic practice on the
> > part of LILO, in my opinion, that ought to have been fixed a long time
> > ago.
>
> And happily passes a "root="
On Tuesday, 15. May 2001 00:54, H. Peter Anvin wrote:
> Alexander Viro wrote:
> > On Mon, 14 May 2001, Alan Cox wrote:
> > > > > Except that Linus wont hand out major numbers, which means I can't
> > > > > even boot simply off such a device. I bet the vendors in question
> > > > > dont think the
On Mon, 14 May 2001, Alan Cox wrote:
>
> Yet another 2.5 project. If Linus wants to go play with name driven devices
> and you want to help him great, but if he'd care to put out
> linux-2.5.0.tar.gz _before_ starting that would be good for all of us
ACK! .. 2.5?? .. gawd .. I just installed
On Mon, 14 May 2001 23:55:37 +0100 (BST),
Alan Cox <[EMAIL PROTECTED]> wrote:
>> > And lilo ?
>Also hdparm
>raidtools
>psmisc
>mtools
>mt-st
>gpm
>joystick
kmod, /etc/modules.conf:
alias block-major-what-random-number-did-the-kernel-pick-this-time driver_name
-
To unsubscribe from this list:
On Mon, 14 May 2001, Alan Cox wrote:
> > 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
> Why can't we configure this in user space? I think of something like
> /etc/major-numbers. We could then tell the kernel at module load time what
> major number to use for a given driver.
We've got one of those lists. H Peter Anvin maintains it.
Don't get me wrong - if in 2.5.x someone can
On Mon, May 14, 2001 at 11:21:00PM +0100, Alan Cox wrote:
> You can make it a string if you like but at the end of the day
> has to be an opaque handle. For constant devices it also has to be
> a constant name. Otherwise the /dev file I archived with the corporate
>
Andi Kleen writes:
> 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
Alan Cox writes:
> > Oh, _that_ one. pass rootname=driver!name (or whatever syntax
> > you prefer) to the kernel and call do_mount() instead of sys_mknod() in
> > prepare_namespace() (rootfs patch). BFD.
>
> Yet another 2.5 project. If Linus wants to go play with name driven
> devices and you
Alan Cox writes:
> > > (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
> >
> > 323
> > Also hdparm
> > raidtools
> > psmisc
> > mtools
> > mt-st
> > gpm
> > joystick
>
> so we now have a list of stuff that needs to be fixed 8)
> or at least, a cross section sampling of stuff to design a new API for.
Yes. Most of it actually uses the major stuff to answer the
On Mon, 14 May 2001, Alan Cox wrote:
> grep MAJOR lilo-21.4.4/*|wc -l
> 323
/me looks and barfs.
Alan, had you actually looked at it? It will require massive changes
whenever you introduce new major. And most of such areas are stuff
that doesn't matter for new devices anyway - geometry,
On Mon, 14 May 2001, Alan Cox wrote:
> > Oh, _that_ one. pass rootname=driver!name (or whatever syntax
> > you prefer) to the kernel and call do_mount() instead of sys_mknod() in
> > prepare_namespace() (rootfs patch). BFD.
>
> Yet another 2.5 project. If Linus wants to go play with name
> > it to a device number at /sbin/lilo time. An idiotic practice on the
> > part of LILO, in my opinion, that ought to have been fixed a long time
> > ago.
>
> That's why you want mount-root-by-partition-label, not by device
Which in itself adds the 'and how does the label tell me what
In article <[EMAIL PROTECTED]> you wrote:
> That's not the issue. LILO takes whatever you pass to root= and converts
> it to a device number at /sbin/lilo time. An idiotic practice on the
> part of LILO, in my opinion, that ought to have been fixed a long time
> ago.
That's why you want
On Mon, 14 May 2001, Alan Cox wrote:
> grep MAJOR lilo-21.4.4/*|wc -l
> 323
> Also hdparm
> raidtools
> psmisc
> mtools
> mt-st
> gpm
> joystick
so we now have a list of stuff that needs to be fixed 8)
or at least, a cross section sampling of stuff to design a new API for.
-Dan
-
To
On Mon, 14 May 2001, H. Peter Anvin wrote:
> > LILO uses BIOS, for fsck sake. It couldn't care less for device numbers
> > on the kernel side. Ask Andries how much do they have in common with
> > BIOS drive numbers.
> >
>
> That's not the issue. LILO takes whatever you pass to root= and
> > And lilo ?
>
> LILO uses BIOS, for fsck sake. It couldn't care less for device numbers
> on the kernel side. Ask Andries how much do they have in common with
> BIOS drive numbers.
grep MAJOR lilo-21.4.4/*|wc -l
323
Also hdparm
raidtools
psmisc
mtools
mt-st
gpm
joystick
and that is a
> Oh, _that_ one. pass rootname=driver!name (or whatever syntax
> you prefer) to the kernel and call do_mount() instead of sys_mknod() in
> prepare_namespace() (rootfs patch). BFD.
Yet another 2.5 project. If Linus wants to go play with name driven devices
and you want to help him great, but if
On Mon, 14 May 2001, Alan Cox wrote:
> > > Except that Linus wont hand out major numbers, which means I can't even boot
> > > simply off such a device. I bet the vendors in question dont think the sun
> > > shines out of linus backside any more.
> >
> > Not really. Special-casing for mounting
> > Except that Linus wont hand out major numbers, which means I can't even boot
> > simply off such a device. I bet the vendors in question dont think the sun
> > shines out of linus backside any more.
>
> Not really. Special-casing for mounting root is trivially solvable. BTDT,
> and you've
Alexander Viro wrote:
>
> On Mon, 14 May 2001, Alan Cox wrote:
>
> > > > Except that Linus wont hand out major numbers, which means I can't even boot
> > > > simply off such a device. I bet the vendors in question dont think the sun
> > > > shines out of linus backside any more.
> > >
> > > Not
On Mon, 14 May 2001, Alan Cox wrote:
> > Would you mind demonstrating such wonder? Old devices are still there,
> > AFAICS. Ext2 (reiserfs, devfs, abortion-of-your-choice-fs) still has
> > the ability to create device nodes for them.
>
> Except that Linus wont hand out major numbers, which
> Would you mind demonstrating such wonder? Old devices are still there,
> AFAICS. Ext2 (reiserfs, devfs, abortion-of-your-choice-fs) still has
> the ability to create device nodes for them.
Except that Linus wont hand out major numbers, which means I can't even boot
simply off such a device. I
> 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
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
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
> 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
> 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
> 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
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
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
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
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
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
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
"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
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
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
"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
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
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 bunch of net
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 bunch of net
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 major. (Al
(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 internal
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
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 has
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
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 anything
501 - 600 of 634 matches
Mail list logo
