Alan Cox wrote:
> > 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 m
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
> const
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 ha
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
A
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
> and
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-UNIXis
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
> > 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 polic
> 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, righ
> 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 PROTEC
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 D
> 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
acro
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 d
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 -use
[EMAIL PROTECTED] wrote:
>
> OK - everybody back from San Jose - pity I couldnt come -
> and it is no longer April 1st, so we can continue quarreling
> a little.
>
> Interesting that where I had divided stuff in the trivial part,
> the interesting part and the lot-of-work part we already start
>
> 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.
Sola
> 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 NFSv
OK - everybody back from San Jose - pity I couldnt come -
and it is no longer April 1st, so we can continue quarreling
a little.
Interesting that where I had divided stuff in the trivial part,
the interesting part and the lot-of-work part we already start
fighting on the trivial part. Maybe it is
> 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
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 [mai
[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 e
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
> 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 majord
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 mos
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 d
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
linux-2.4.3-p8/
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 nu
> 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 m
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 neccessaril
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 disk
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 t
"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/
"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 numbe
> > 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 lea
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 mounte
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 seria
On Tue, Mar 27, 2001 at 10:48:13AM -0800, Linus Torvalds wrote:
> 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
> that we u
On Tue, 27 Mar 2001, Johan Kullstam wrote:
>"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
>
>> 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-
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 fa
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 d
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> 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
> 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 p
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.
> >
> > write-
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 of
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 auxilliary mechanisms to
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
"disk"
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 t
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 a
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
> "chmod /dev/foo" work
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 this
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 j
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 make
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 neccessaril
> 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 accurate. A major for 'serial
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 they'd get all the disks.
On Tue, 27 Mar 2001, Linus Torvalds wrote:
>
>
> On Tue, 27 Mar 2001, Alan Cox wrote:
> >
> > > layer made it impossible for a driver writer to be nice to the user, so
> > > instead they got their own major numbers.
> >
> > Not deficiencies in the SCSI layer, there is no way the scsi layer can
On Tue, 27 Mar 2001, Alan Cox wrote:
>
> > layer made it impossible for a driver writer to be nice to the user, so
> > instead they got their own major numbers.
>
> Not deficiencies in the SCSI layer, there is no way the scsi layer can
> handle high end raid controllers. In fact one of the reaso
> 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 they'd get all the disks. Deficiencies in the SCSI
S
On Tue, 27 Mar 2001, H. Peter Anvin wrote:
>
> Part of the reason we haven't -- quite -- run out of 8-bit majors yet is
> because I have been an absolute *bastard* with registrants lately. It
> would cut down on my workload if I could assign majors without worrying
> too much about whether or n
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 ever envision seeing that "ls
[EMAIL PROTECTED] writes:
> [Linus Torvalds]
>> You'e now forced every piece of code that needs a dev_t
>> to carry along the overhead of having a 64-bit field
>
> Let me repeat: there is no such code. In user space dev_t already is
> 64 bits, whether you like it or not. We cannot go back to libc
On Tue, 27 Mar 2001 [EMAIL PROTECTED] wrote:
>
> Let me repeat: there is no such code. In user space dev_t already is
> 64 bits, whether you like it or not. We cannot go back to libc5.
Now you're back to the argument that "glibc is bloated, so we might as
well be too".
The fact is, that I don'
> On Sun, 25 Mar 2001 [EMAIL PROTECTED] wrote:
Aha - after your previous explosion I had concluded that working
on *dev_t was useless, but it seems we are still talking.
>> [a large name space is useful since it allows new types of usage]
> Fine.
> You'e now forced every piece of code that need
On Sun, 25 Mar 2001 [EMAIL PROTECTED] wrote:
>
> Now what I wrote is that *I* am strongly in favor of sizeof(dev_t) = 8.
> You think that I want bloat - in reality sizeof(dev_t) = 8 makes life
> simpler.
>
> My system here has for example in super.c:
>
> static dev_t next_unnamed_device = 0x1000
On Mon, Mar 26, 2001 at 01:18:06PM -0800, John Byrne wrote:
> Do you have any interest in doing away with the concept of major and
> minor numbers altogether; turning the dev_t into an opaque unique id?
>
> At the application level, the kinds of information that is derived from
> the major/minor
On Mon, 26 Mar 2001, John Byrne wrote:
> > Re: Larger dev_t
> >
> On Sat Mar 24 2001 Linus Torvalds ([EMAIL PROTECTED]) wrote:
> > There is no way in HELL I will ever accept a 64-bit dev_t.
> >
> > I _will_ accept a 32-bit dev_t, with 12 bits for major n
> Re: Larger dev_t
>
On Sat Mar 24 2001 Linus Torvalds ([EMAIL PROTECTED]) wrote:
> There is no way in HELL I will ever accept a 64-bit dev_t.
>
> I _will_ accept a 32-bit dev_t, with 12 bits for major numbers, and 20
> bits for minor numbers.
>
Do you have any interest i
On Sun, 25 Mar 2001, Guest section DW wrote:
> On Sun, Mar 25, 2001 at 05:35:01PM +0200, Wichert Akkerman wrote:
> > In article <[EMAIL PROTECTED]>,
> > <[EMAIL PROTECTED]> wrote:
> > >a large name space allows one to omit checking what part can be
> > >reused - reuse is unnecessary.
> >
> > Yo
On Sun, Mar 25, 2001 at 05:35:01PM +0200, Wichert Akkerman wrote:
> In article <[EMAIL PROTECTED]>,
> <[EMAIL PROTECTED]> wrote:
> >a large name space allows one to omit checking what part can be
> >reused - reuse is unnecessary.
>
> You are just delaying the problem then, at some point your upt
Ok, i don't really know much about the kernel at all, but here's my opinion
anyway..
To use 64bit pids when 32bit is enough just to "make things easier" doesn't
sound like a good idea to me. Eventually it might wrap around (fx. as on that
supercomputer Jamie Lokier talked about) to overwrite r
> Ever heard of cut-and-paste? Surely you can afford a mouse... And
> for when
> you you are not inputting manually but running a script/whatever,
> who cares
> what the numbers are...
>
> Cheers,
>
> Anton
Oops. Okay, you're right.
-
To unsubscribe from this list: send the line "u
Michel Wilson wrote:
> Ever thought about how you would kill a process: kill -9 127892752 doesn't
> sound very appealing to me.
man killall(1). Kill processes by name.
> So you'd also need to implement a mechanism that allows for 'easy' selection
> of processes to kill, for example giving every
Mitchell Blank Jr wrote:
> Wichert Akkerman wrote:
> > You are just delaying the problem then, at some point your uptime will
> > be large enough that you have run through all 64bit pids for example.
>
> 64 bits is enough to fork 1 million processes per second for over
> 500,000 years. I think t
At 17:54 25/03/2001, Michel Wilson wrote:
> > Wichert Akkerman wrote:
> > > You are just delaying the problem then, at some point your uptime will
> > > be large enough that you have run through all 64bit pids for example.
> >
> > 64 bits is enough to fork 1 million processes per second for over
>
> Wichert Akkerman wrote:
> > You are just delaying the problem then, at some point your uptime will
> > be large enough that you have run through all 64bit pids for example.
>
> 64 bits is enough to fork 1 million processes per second for over
> 500,000 years. I think that's putting the problem
Wichert Akkerman wrote:
> You are just delaying the problem then, at some point your uptime will
> be large enough that you have run through all 64bit pids for example.
64 bits is enough to fork 1 million processes per second for over
500,000 years. I think that's putting the problem off far eno
In article <[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
>a large name space allows one to omit checking what part can be
>reused - reuse is unnecessary.
You are just delaying the problem then, at some point your uptime will
be large enough that you have run through all 64bit pids for example.
Linus Torvalds wrote:
>
> On Sat, 24 Mar 2001 [EMAIL PROTECTED] wrote:
> >
> > We need a size, and I am strongly in favor of sizeof(dev_t) = 8;
> > this is already true in glibc.
>
> The fact that glibc is a quivering mass of bloat, and total and utter crap
> makes you suggest that the Linux ker
Jeff Garzik wrote:
>
> Also for 2.5, kdev_t needs to go away, along with all those arrays based
> on major number, and be replaced with either "struct char_device" or
> "struct block_device" depending on the device.
>
> I actually went through the kernel in 2.4.0-test days and did this.
> Most k
From [EMAIL PROTECTED] Sun Mar 25 05:26:51 2001
On Sat, 24 Mar 2001 [EMAIL PROTECTED] wrote:
>
> We need a size, and I am strongly in favor of sizeof(dev_t) = 8;
> this is already true in glibc.
The fact that glibc is a quivering mass of bloat, and total and utter crap
On Sat, 24 Mar 2001 [EMAIL PROTECTED] wrote:
>
> We need a size, and I am strongly in favor of sizeof(dev_t) = 8;
> this is already true in glibc.
The fact that glibc is a quivering mass of bloat, and total and utter crap
makes you suggest that the Linux kernel should try to be as similar as
po
> Also for 2.5, kdev_t needs to go away, along with all those arrays
Yes, it has been said many times, and I get the impression
that many people actually did it.
Maybe everybody with code or at least a detailed setup
should demonstrate what was done so that we can compare merits
of several appro
On Sat, 24 Mar 2001, Jeff Garzik wrote:
> Also for 2.5, kdev_t needs to go away, along with all those arrays based
> on major number, and be replaced with either "struct char_device" or
> "struct block_device" depending on the device.
>
> I actually went through the kernel in 2.4.0-test days a
Also for 2.5, kdev_t needs to go away, along with all those arrays based
on major number, and be replaced with either "struct char_device" or
"struct block_device" depending on the device.
I actually went through the kernel in 2.4.0-test days and did this.
Most kdev_t usages should really be cha
94 matches
Mail list logo