On Tue, Apr 03, 2001 at 02:20:24PM +0200, Ingo Oeser wrote:
> On Tue, Apr 03, 2001 at 01:06:33PM +0100, Alan Cox wrote:
> > Device numbers/names have to be constant in order to detect
> > disk layout changes across boots.
>
> Names stay constant, but why the NUMBERS? The names should stay
>
Alan Cox writes:
> > However, a large number of people run devfs on small to large systems,
> > and these "races" aren't causing problems. People tell me it's quite
>
> They dont have users actively trying to exploit them. I don't
> consider it a big problem for development trees though. devfs
Alexander Viro writes:
>
>
> On Tue, 3 Apr 2001, Richard Gooch wrote:
>
> > However, a large number of people run devfs on small to large systems,
> > and these "races" aren't causing problems. People tell me it's quite
> > stable. I run devfs on my systems, and not once have I had a problem
>
> However, a large number of people run devfs on small to large systems,
> and these "races" aren't causing problems. People tell me it's quite
They dont have users actively trying to exploit them. I don't consider it a
big problem for development trees though. devfs has a maintainer at least
On Tue, 3 Apr 2001, Richard Gooch wrote:
> However, a large number of people run devfs on small to large systems,
> and these "races" aren't causing problems. People tell me it's quite
> stable. I run devfs on my systems, and not once have I had a problem
> due to devfs "races". So I feel it's
Alan Cox writes:
> > > One thing I certainly miss: DevFS is not mandatory (yet).
> >
> > That's "only" due to the fact that DevFS is an insanely racy and
> > instable
> > piece of CRAP. I'm unhappy it's there anyway...
>
> It certainly seems to have some race conditions but other than that
>
On Tue, 3 Apr 2001, [EMAIL PROTECTED] wrote:
> Ingo Oeser <[EMAIL PROTECTED]> wrote:
>
> >Yes: Let "mknod /dev/foo [bc] x y" die!
>
> I hope this never happens. Improving the major/minor device scheme is
> reasonable; abandoning it would be a sad occurrence. It would make Linux too
>
Ingo Oeser <[EMAIL PROTECTED]> wrote:
>Yes: Let "mknod /dev/foo [bc] x y" die!
I hope this never happens. Improving the major/minor device scheme is
reasonable; abandoning it would be a sad occurrence. It would make Linux too
"un-UNIXish" (how's THAT for an an ugly neologism!) for my
> > One thing I certainly miss: DevFS is not mandatory (yet).
>
> That's "only" due to the fact that DevFS is an insanely racy and
> instable
> piece of CRAP. I'm unhappy it's there anyway...
It certainly seems to have some race conditions but other than that and the
slight problem it puts
> Names stay constant, but why the NUMBERS? The names should stay
> constant and represent the actual layout on each busses (say:
> sane hierachic enumeration) of course.
You can do it that way too
> But /dev/ide/host0/bus0/target0/lun0/part1 could get a new device
> number on every reboot,
> What's worth it to be able running 2.0 and 2.4 on the same box?
> I just intendid to tell you that there are actually people in the
> REAL BUSINESS out there who know about and are willing to sacifier
> compatibility until perpetuum for contignouus developement.
And many people who require the
> One thing I certainly miss: DevFS is not mandatory (yet).
That's "only" due to the fact that DevFS is an insanely racy and
instable
piece of CRAP. I'm unhappy it's there anyway...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Alan Cox wrote:
>
> > If anything I'm a *SERIOUS* production user. And I wouldn't allow
> > *ANYBODY* here to run am explicitly tagged as developement kernel
> > here anyway in an production enviornment. That's what releases are for
> > damn.
> > Or do you think that Linux should still preserve
> If anything I'm a *SERIOUS* production user. And I wouldn't allow
> *ANYBODY* here to run am explicitly tagged as developement kernel
> here anyway in an production enviornment. That's what releases are for
> damn.
> Or do you think that Linux should still preserve DOS compatibility
> in to the
On Tue, Apr 03, 2001 at 01:06:33PM +0100, Alan Cox wrote:
> Device numbers/names have to be constant in order to detect
> disk layout changes across boots.
Names stay constant, but why the NUMBERS? The names should stay
constant and represent the actual layout on each busses (say:
sane hierachic
> Device numbers have to be uniqe only during one power on -> run ->
> power off cycle. For the rest applications should store device
> names instead anyway. The applications, that don't are buggy by
> defintion.
Device numbers/names have to be constant in order to detect disk layout changes
On Mon, Apr 02, 2001 at 10:17:02PM +0200, [EMAIL PROTECTED] wrote:
> What is dev_t used for? It is a communication channel from
> filesystem to user space (via the stat() system call)
> and from user space to filesystem (via the mknod() system call).
The question is WHAT do we communicate (and
Alan Cox wrote:
>
> > So change them as well for a new distribution. What's there problem.
> > There isn't anything out there you can't do by hand.
> > Fortunately so!
>
> So users cannot go back and forward between new and old kernels. Very good.
> Try explaining that to serious production
part we already start
> fighting on the trivial part. Maybe it is not very important -
> still I'd prefer to do things right from the start.
>
> Yes. We need a larger dev_t as everybody agrees.
> How large?
>
> What is dev_t used for? It is a communication channel from
> fi
Alan Cox wrote:
So change them as well for a new distribution. What's there problem.
There isn't anything out there you can't do by hand.
Fortunately so!
So users cannot go back and forward between new and old kernels. Very good.
Try explaining that to serious production -users- of a
On Mon, Apr 02, 2001 at 10:17:02PM +0200, [EMAIL PROTECTED] wrote:
What is dev_t used for? It is a communication channel from
filesystem to user space (via the stat() system call)
and from user space to filesystem (via the mknod() system call).
The question is WHAT do we communicate (and
Device numbers have to be uniqe only during one power on - run -
power off cycle. For the rest applications should store device
names instead anyway. The applications, that don't are buggy by
defintion.
Device numbers/names have to be constant in order to detect disk layout changes
across
On Tue, Apr 03, 2001 at 01:06:33PM +0100, Alan Cox wrote:
Device numbers/names have to be constant in order to detect
disk layout changes across boots.
Names stay constant, but why the NUMBERS? The names should stay
constant and represent the actual layout on each busses (say:
sane hierachic
If anything I'm a *SERIOUS* production user. And I wouldn't allow
*ANYBODY* here to run am explicitly tagged as developement kernel
here anyway in an production enviornment. That's what releases are for
damn.
Or do you think that Linux should still preserve DOS compatibility
in to the
Alan Cox wrote:
If anything I'm a *SERIOUS* production user. And I wouldn't allow
*ANYBODY* here to run am explicitly tagged as developement kernel
here anyway in an production enviornment. That's what releases are for
damn.
Or do you think that Linux should still preserve DOS
One thing I certainly miss: DevFS is not mandatory (yet).
That's "only" due to the fact that DevFS is an insanely racy and
instable
piece of CRAP. I'm unhappy it's there anyway...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
What's worth it to be able running 2.0 and 2.4 on the same box?
I just intendid to tell you that there are actually people in the
REAL BUSINESS out there who know about and are willing to sacifier
compatibility until perpetuum for contignouus developement.
And many people who require the
Names stay constant, but why the NUMBERS? The names should stay
constant and represent the actual layout on each busses (say:
sane hierachic enumeration) of course.
You can do it that way too
But /dev/ide/host0/bus0/target0/lun0/part1 could get a new device
number on every reboot, right?
One thing I certainly miss: DevFS is not mandatory (yet).
That's "only" due to the fact that DevFS is an insanely racy and
instable
piece of CRAP. I'm unhappy it's there anyway...
It certainly seems to have some race conditions but other than that and the
slight problem it puts policy in
Ingo Oeser [EMAIL PROTECTED] wrote:
Yes: Let "mknod /dev/foo [bc] x y" die!
I hope this never happens. Improving the major/minor device scheme is
reasonable; abandoning it would be a sad occurrence. It would make Linux too
"un-UNIXish" (how's THAT for an an ugly neologism!) for my tastes.
On Tue, 3 Apr 2001, [EMAIL PROTECTED] wrote:
Ingo Oeser [EMAIL PROTECTED] wrote:
Yes: Let "mknod /dev/foo [bc] x y" die!
I hope this never happens. Improving the major/minor device scheme is
reasonable; abandoning it would be a sad occurrence. It would make Linux too
"un-UNIXish"
Alan Cox writes:
One thing I certainly miss: DevFS is not mandatory (yet).
That's "only" due to the fact that DevFS is an insanely racy and
instable
piece of CRAP. I'm unhappy it's there anyway...
It certainly seems to have some race conditions but other than that
and the slight
On Tue, 3 Apr 2001, Richard Gooch wrote:
However, a large number of people run devfs on small to large systems,
and these "races" aren't causing problems. People tell me it's quite
stable. I run devfs on my systems, and not once have I had a problem
due to devfs "races". So I feel it's
However, a large number of people run devfs on small to large systems,
and these "races" aren't causing problems. People tell me it's quite
They dont have users actively trying to exploit them. I don't consider it a
big problem for development trees though. devfs has a maintainer at least
Alexander Viro writes:
On Tue, 3 Apr 2001, Richard Gooch wrote:
However, a large number of people run devfs on small to large systems,
and these "races" aren't causing problems. People tell me it's quite
stable. I run devfs on my systems, and not once have I had a problem
due to
Alan Cox writes:
However, a large number of people run devfs on small to large systems,
and these "races" aren't causing problems. People tell me it's quite
They dont have users actively trying to exploit them. I don't
consider it a big problem for development trees though. devfs has a
On Tue, Apr 03, 2001 at 02:20:24PM +0200, Ingo Oeser wrote:
On Tue, Apr 03, 2001 at 01:06:33PM +0100, Alan Cox wrote:
Device numbers/names have to be constant in order to detect
disk layout changes across boots.
Names stay constant, but why the NUMBERS? The names should stay
constant and
> Mount NFS device areas with NFSv2. Thats the standard workaround
Oh, sure. We survived with 16 bits and we'll survive with 32.
Nevertheless it is a bad sign that you have to start talking
about workarounds even before the new system has been implemented.
(And NFSv2 has its quirks as well.
> Not using 64 also gives interesting small problems with Solaris or
> FreeBSD NFS mounts. One uses 14+18, the other 8+24, so with 12+20
> we cannot handle Solaris' majors and we cannot handle FreeBSD's minors.
Mount NFS device areas with NFSv2. Thats the standard workaround for the
fact the
it is not very important -
still I'd prefer to do things right from the start.
Yes. We need a larger dev_t as everybody agrees.
How large?
What is dev_t used for? It is a communication channel from
filesystem to user space (via the stat() system call)
and from user space to filesystem (via the mknod
> So change them as well for a new distribution. What's there problem.
> There isn't anything out there you can't do by hand.
> Fortunately so!
So users cannot go back and forward between new and old kernels. Very good.
Try explaining that to serious production -users- of a system and see how
So change them as well for a new distribution. What's there problem.
There isn't anything out there you can't do by hand.
Fortunately so!
So users cannot go back and forward between new and old kernels. Very good.
Try explaining that to serious production -users- of a system and see how
it
it is not very important -
still I'd prefer to do things right from the start.
Yes. We need a larger dev_t as everybody agrees.
How large?
What is dev_t used for? It is a communication channel from
filesystem to user space (via the stat() system call)
and from user space to filesystem (via the mknod
Not using 64 also gives interesting small problems with Solaris or
FreeBSD NFS mounts. One uses 14+18, the other 8+24, so with 12+20
we cannot handle Solaris' majors and we cannot handle FreeBSD's minors.
Mount NFS device areas with NFSv2. Thats the standard workaround for the
fact the NFSv3
Mount NFS device areas with NFSv2. Thats the standard workaround
Oh, sure. We survived with 16 bits and we'll survive with 32.
Nevertheless it is a bad sign that you have to start talking
about workarounds even before the new system has been implemented.
(And NFSv2 has its quirks as well.
Hi-
Tangential question (I think). Not for an IOCTL request 8;)
[as the JFS request last week].
[When] is it OK to use (new) IOCTLs vs. using procfs read/write?
And are there some alternative methods besides these two?
Thanks,
~Randy
> -Original Message-
> From: Linus Torvalds
Hi-
Tangential question (I think). Not for an IOCTL request 8;)
[as the JFS request last week].
[When] is it OK to use (new) IOCTLs vs. using procfs read/write?
And are there some alternative methods besides these two?
Thanks,
~Randy
-Original Message-
From: Linus Torvalds
[EMAIL PROTECTED] (Martin Dalecki) wrote on 28.03.01 in
<[EMAIL PROTECTED]>:
> Alan Cox wrote:
> >
> > > Exactly. It's just that for historical reasons, I think the major for
> > > "disk" should be either the old IDE or SCSI one, which just can show
> > > more devices. That way old installers
Alan Cox wrote:
>
> > Why do you worry about installers? New distro - new kernel - new
> > installer
>
> Because the same code tends to be shared with post install configuration
> tools too.
So change them as well for a new distribution. What's there problem.
There isn't anything out there you
Alan Cox wrote:
Why do you worry about installers? New distro - new kernel - new
installer
Because the same code tends to be shared with post install configuration
tools too.
So change them as well for a new distribution. What's there problem.
There isn't anything out there you can't
[EMAIL PROTECTED] (Martin Dalecki) wrote on 28.03.01 in
[EMAIL PROTECTED]:
Alan Cox wrote:
Exactly. It's just that for historical reasons, I think the major for
"disk" should be either the old IDE or SCSI one, which just can show
more devices. That way old installers etc work
> Why do you worry about installers? New distro - new kernel - new
> installer
Because the same code tends to be shared with post install configuration
tools too.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
Alan Cox wrote:
>
> > Exactly. It's just that for historical reasons, I think the major for
> > "disk" should be either the old IDE or SCSI one, which just can show more
> > devices. That way old installers etc work without having to suddenly start
> > knowing about /dev/disk0.
>
> They will
On Wed, 28 Mar 2001, H. Peter Anvin wrote:
> Martin Dalecki wrote:
> > >
> > > devfs -- in the abstract -- really isn't that bad of an idea; after all,
> >
> > Devfs is from a desing point of view the duplication for the bad /proc
> > design for devices. If you need a good design for general
On Wed, 28 Mar 2001, Martin Dalecki wrote:
> Then please please please demangle other cases as well!
> IDE is the one which is badging my head most. SCSI as well...
>
> Granted I wouldn't mind a rebot with new /dev/* once!
diff -urN linux-2.4.3-p8-pristine/include/linux/major.h
Martin Dalecki wrote:
>
> Then please please please demangle other cases as well!
> IDE is the one which is badging my head most. SCSI as well...
>
> Granted I wouldn't mind a rebot with new /dev/* once!
>
This seems to me to really be the kind of thing devfs does better than
trying to play
> what do other vaguely unix-like systems do? does, say, plan9 have a
> better way of dealing with all this?
Yes.
Normal UNIX has as well. For reffernece see: block ver raw
devices on docs.sun.com :-).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Alan Cox wrote:
>
> > high-end-disks. Rather the reverse. I'm advocating the SCSI layer not
> > hogging a major number, but letting low-level drivers get at _their_
> > requests directly.
>
> A major for 'disk' generically makes total sense. Classing raid controllers
> as 'scsi' isnt
Linus Torvalds wrote:
>
> On Tue, 27 Mar 2001, Andre Hedrick wrote:
> >
> > Am I hearing you state you want dynamic device points and dynamic majors?
>
> Yes and no.
>
> We need static structures for user space - from a user perspective it
> makes a ton more sense to say "I want to see all
Martin Dalecki wrote:
> >
> > devfs -- in the abstract -- really isn't that bad of an idea; after all,
>
> Devfs is from a desing point of view the duplication for the bad /proc
> design for devices. If you need a good design for general device
> handling with names - network interfaces are the
"H. Peter Anvin" wrote:
>
> Alan Cox wrote:
> >
> > > Another example: all the stupid pseudo-SCSI drivers that got their own
> > > major numbers, and wanted their very own names in /dev. They are BAD for
> > > the user. Install-scripts etc used to be able to just test /dev/hd[a-d]
> > > and
"H. Peter Anvin" wrote:
>
> This is my opinion on the issue. Short summary: "I'm sick of the
> administrative burden associated with keeping dev_t dense."
>
> Linus Torvalds wrote:
> >
> > And let's take a look at /dev. Do a "ls -l /dev" and think about it. Every
> > device needs a unique
> > And what would you do if the names collide ?
>
> refuse to mount - give the admin time to fix them in single user mode
That means that it could only be used for optional filesystems otherwise
booting unattended is put into question.
A user set for a practical joke could prevent booting by
Oliver Neukum <[EMAIL PROTECTED]>:
>
> > My suggestion would be to add a filesystem label (optional) to the
> > homeblock of all filesystmes, then load that identifier into the
> > /proc/partitions file. This would allow a search to locate the
> > device parameters for any filesystem being
Russell King wrote:
> I for one would like to see a major number for all 'serial ports' whether
> they be embedded ARM serial ports _or_ standard 16550 ports, but at the
> moment its not easily acheivable without introducing more mess.
>
> Ted indicated to me a while ago (just after I wrote
ld help deal with "same device, different options" such as
>> /dev/ttyS0 versus /dev/cua0 -- having flags to open() is really ugly
>> since there tends to be no easy way to pass them down through multiple
>> layers of user-space code.)
>>
>> The problems with devfs
On Tue, 27 Mar 2001, Linus Torvalds wrote:
> ... lots of stuff removed ...
>
> So in /dev, there are two problems: we are getting painfully close to
> major numbers with 8 bits, and we've run out of minors several times. In
> fact, a lot of the reason for the dearthness of major numbers is the
On Tue, 27 Mar 2001, Linus Torvalds wrote:
... lots of stuff removed ...
So in /dev, there are two problems: we are getting painfully close to
major numbers with 8 bits, and we've run out of minors several times. In
fact, a lot of the reason for the dearthness of major numbers is the fact
ch guaranteed to be much worse than the bloat a larger dev_t would
entail) is that it needs complex auxilliary mechanisms to make
"chmod /dev/foo" work as expected (the change to /dev/foo is to be
permanent, without having to edit some silly config file)
the permanent storage for a PC
Russell King wrote:
I for one would like to see a major number for all 'serial ports' whether
they be embedded ARM serial ports _or_ standard 16550 ports, but at the
moment its not easily acheivable without introducing more mess.
Ted indicated to me a while ago (just after I wrote
Oliver Neukum [EMAIL PROTECTED]:
My suggestion would be to add a filesystem label (optional) to the
homeblock of all filesystmes, then load that identifier into the
/proc/partitions file. This would allow a search to locate the
device parameters for any filesystem being mounted. If the
And what would you do if the names collide ?
refuse to mount - give the admin time to fix them in single user mode
That means that it could only be used for optional filesystems otherwise
booting unattended is put into question.
A user set for a practical joke could prevent booting by
"H. Peter Anvin" wrote:
This is my opinion on the issue. Short summary: "I'm sick of the
administrative burden associated with keeping dev_t dense."
Linus Torvalds wrote:
And let's take a look at /dev. Do a "ls -l /dev" and think about it. Every
device needs a unique number. Do you
"H. Peter Anvin" wrote:
Alan Cox wrote:
Another example: all the stupid pseudo-SCSI drivers that got their own
major numbers, and wanted their very own names in /dev. They are BAD for
the user. Install-scripts etc used to be able to just test /dev/hd[a-d]
and /dev/sd[0-x] and
Martin Dalecki wrote:
devfs -- in the abstract -- really isn't that bad of an idea; after all,
Devfs is from a desing point of view the duplication for the bad /proc
design for devices. If you need a good design for general device
handling with names - network interfaces are the thing
Alan Cox wrote:
high-end-disks. Rather the reverse. I'm advocating the SCSI layer not
hogging a major number, but letting low-level drivers get at _their_
requests directly.
A major for 'disk' generically makes total sense. Classing raid controllers
as 'scsi' isnt neccessarily
Linus Torvalds wrote:
On Tue, 27 Mar 2001, Andre Hedrick wrote:
Am I hearing you state you want dynamic device points and dynamic majors?
Yes and no.
We need static structures for user space - from a user perspective it
makes a ton more sense to say "I want to see all disks" than it
what do other vaguely unix-like systems do? does, say, plan9 have a
better way of dealing with all this?
Yes.
Normal UNIX has as well. For reffernece see: block ver raw
devices on docs.sun.com :-).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Martin Dalecki wrote:
Then please please please demangle other cases as well!
IDE is the one which is badging my head most. SCSI as well...
Granted I wouldn't mind a rebot with new /dev/* once!
This seems to me to really be the kind of thing devfs does better than
trying to play number
On Wed, 28 Mar 2001, H. Peter Anvin wrote:
Martin Dalecki wrote:
devfs -- in the abstract -- really isn't that bad of an idea; after all,
Devfs is from a desing point of view the duplication for the bad /proc
design for devices. If you need a good design for general device
Alan Cox wrote:
Exactly. It's just that for historical reasons, I think the major for
"disk" should be either the old IDE or SCSI one, which just can show more
devices. That way old installers etc work without having to suddenly start
knowing about /dev/disk0.
They will mostly break.
Why do you worry about installers? New distro - new kernel - new
installer
Because the same code tends to be shared with post install configuration
tools too.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
On Wed, 28 Mar 2001, Alan Cox wrote:
> They will mostly break. Installers tend to parse /proc/scsi and have fairly
> complex ioctl based relationships based on knowing ide v scsi.
>
> /dev/disc/ is a little un-unix but its clean
Then make a '/proc/block/{ide|scsi|raid|wtf|ram|net}' which has a
On 27 Mar 2001, Johan Kullstam wrote:
> it might be a mostly userspace solvable problem. a device daemon
> could create new devices on the fly, only they'd be ordinary
> filesystem devices. for example it might be better to hack ls to not
> show dormant devices. a cronjob could call a grim
tends to be no easy way to pass them down through multiple
> layers of user-space code.)
>
> The problems with devfs (other than kernel memory bloat, which is pretty
> much guaranteed to be much worse than the bloat a larger dev_t would
> entail) is that it needs complex auxilliary mec
> Exactly. It's just that for historical reasons, I think the major for
> "disk" should be either the old IDE or SCSI one, which just can show more
> devices. That way old installers etc work without having to suddenly start
> knowing about /dev/disk0.
They will mostly break. Installers tend to
On Wed, 28 Mar 2001, Paul Jakma wrote:
> On Tue, 27 Mar 2001, Dan Hollis wrote:
>
> > On Tue, 27 Mar 2001, H. Peter Anvin wrote:
> > > c) Make sure chown/chmod/link/symlink/rename/rm etc does the right thing,
> > > without the need for "tar hacks" or anything equivalently gross.
> >
> >
On Tue, 27 Mar 2001, Dan Hollis wrote:
> On Tue, 27 Mar 2001, H. Peter Anvin wrote:
> > c) Make sure chown/chmod/link/symlink/rename/rm etc does the right thing,
> > without the need for "tar hacks" or anything equivalently gross.
>
> write-through filesystem, like overlaying a r/w ext2 on top
Andrew Pimlott writes:
> On Tue, Mar 27, 2001 at 02:13:47PM -0800, H. Peter Anvin wrote:
>> The problems with devfs (other than kernel memory bloat, which is pretty
>> much guaranteed to be much worse than the bloat a larger dev_t would
>> entail) is that it needs complex
On Tue, 27 Mar 2001, H. Peter Anvin wrote:
>
> They would still have to change, since now we'd have to worry about
> /dev/hd* having changed meanings;
This is why I'd select the SCSI major, which has always had more of a
"random disk" connotation, with fewer people being aware of the fact that
On Tue, 27 Mar 2001, Alan Cox wrote:
>
> A major for 'disk' generically makes total sense. Classing raid controllers
> as 'scsi' isnt neccessarily accurate. A major for 'serial ports' would also
> solve a lot of misery
Exactly. It's just that for historical reasons, I think the major for
Linus Torvalds wrote:
>
> On Tue, 27 Mar 2001, Alan Cox wrote:
> >
> > A major for 'disk' generically makes total sense. Classing raid controllers
> > as 'scsi' isnt neccessarily accurate. A major for 'serial ports' would also
> > solve a lot of misery
>
> Exactly. It's just that for historical
On Tue, 27 Mar 2001, Andre Hedrick wrote:
>
> Am I hearing you state you want dynamic device points and dynamic majors?
Yes and no.
We need static structures for user space - from a user perspective it
makes a ton more sense to say "I want to see all disks" than it does to
know that you have
H. Peter Anvin writes:
> Dan Hollis wrote:
> >
> > On Tue, 27 Mar 2001, H. Peter Anvin wrote:
> > > c) Make sure chown/chmod/link/symlink/rename/rm etc does the right thing,
> > > without the need for "tar hacks" or anything equivalently gross.
> >
> > write-through filesystem, like overlaying
On Tue, Mar 27, 2001 at 02:13:47PM -0800, H. Peter Anvin wrote:
> The problems with devfs (other than kernel memory bloat, which is pretty
> much guaranteed to be much worse than the bloat a larger dev_t would
> entail) is that it needs complex auxilliary mechanisms to make
> &qu
Dan Hollis wrote:
>
> On Tue, 27 Mar 2001, H. Peter Anvin wrote:
> > c) Make sure chown/chmod/link/symlink/rename/rm etc does the right thing,
> > without the need for "tar hacks" or anything equivalently gross.
>
> write-through filesystem, like overlaying a r/w ext2 on top of an iso9660
> fs.
On Tue, 27 Mar 2001, H. Peter Anvin wrote:
> c) Make sure chown/chmod/link/symlink/rename/rm etc does the right thing,
> without the need for "tar hacks" or anything equivalently gross.
write-through filesystem, like overlaying a r/w ext2 on top of an iso9660
fs.
-Dan
-
To unsubscribe from
On Tue, Mar 27, 2001 at 02:16:37PM -0800, H. Peter Anvin wrote:
> Alan Cox wrote:
> > A major for 'disk' generically makes total sense. Classing raid controllers
> > as 'scsi' isnt neccessarily accurate. A major for 'serial ports' would also
> > solve a lot of misery
>
> But it might also cause
Jesse Pollard wrote:
> > >
> > > > high-end-disks. Rather the reverse. I'm advocating the SCSI layer not
> > > > hogging a major number, but letting low-level drivers get at _their_
> > > > requests directly.
> > >
> > > A major for 'disk' generically makes total sense. Classing raid controllers
- Received message begins Here -
>
> Alan Cox wrote:
> >
> > > high-end-disks. Rather the reverse. I'm advocating the SCSI layer not
> > > hogging a major number, but letting low-level drivers get at _their_
> > > requests directly.
> >
> > A major for 'disk' generically
1 - 100 of 183 matches
Mail list logo
