public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* Re: Larger dev_t
@ 2001-04-02 20:17 Andries.Brouwer
  2001-04-02 21:45 ` Alan Cox
                   ` (2 more replies)
  0 siblings, 3 replies; 95+ messages in thread
From: Andries.Brouwer @ 2001-04-02 20:17 UTC (permalink / raw)
  To: Andries.Brouwer, torvalds; +Cc: alan, hpa, linux-kernel, tytso

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 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() system call).

So, it seems the kernel interface must allow passing the values
that actually occur, in present or future file systems.
Making the interface narrow is only asking for problems later.
Are there already any filesystems that use 64-bits?
I would say that that is irrelevant - what we don't have today
may come tomorrow - but in fact the NFSv3 interface uses
a 64-bit device number.

So glibc comes with 64 bits, the kernel has to hand these bits
over to NFS but is unwilling to - you are not going to get
more than 32. Why?

> I have a holy crusade.

I fail to see the connection. There is no bloat here, the kernel
is hardly involved. Some values are passed. If the values are
larger than the filesystem likes it will probably return EINVAL.
But the kernel has no business getting in the way.

There is no matter of efficiency either - mknod is not precisely
the most frequently used system call, and our stat interface, which
really is important, is 64 bits today.

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.

[Then there were discussions about naming.
These are interesting, but independent.
The current discussion is almost entirely about mknod.]

Andries

^ permalink raw reply	[flat|nested] 95+ messages in thread
* Re: Larger dev_t
@ 2001-04-03 14:48 Wayne.Brown
  2001-04-03 15:34 ` Bart Trojanowski
  0 siblings, 1 reply; 95+ messages in thread
From: Wayne.Brown @ 2001-04-03 14:48 UTC (permalink / raw)
  To: Ingo Oeser; +Cc: Andries.Brouwer, torvalds, alan, hpa, linux-kernel, tytso



Ingo Oeser <ingo.oeser@informatik.tu-chemnitz.de> 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.

Wayne



^ permalink raw reply	[flat|nested] 95+ messages in thread
* Re: Larger dev_t
@ 2001-04-02 21:59 Andries.Brouwer
  0 siblings, 0 replies; 95+ messages in thread
From: Andries.Brouwer @ 2001-04-02 21:59 UTC (permalink / raw)
  To: Andries.Brouwer, alan; +Cc: hpa, linux-kernel, torvalds, tytso

> 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.
Solaris will split the 32-bit number (the size given in a CREATE
request) into 14+18 when it is not a 16-bit value, while it will
split it into 8+8 if it is. FreeBSD will regard it as a 8+24 dev_t.
So, in general, different systems will parse the same dev_t in
different ways, and hence see different (major,minor) for the
same device.)

Andries

^ permalink raw reply	[flat|nested] 95+ messages in thread
* Re: Larger dev_t
@ 2001-03-27 22:38 Jesse Pollard
  2001-03-27 22:44 ` H. Peter Anvin
  0 siblings, 1 reply; 95+ messages in thread
From: Jesse Pollard @ 2001-03-27 22:38 UTC (permalink / raw)
  To: hpa, Alan Cox; +Cc: Linus Torvalds, Andries.Brouwer, linux-kernel, tytso

---------  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 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 just as much misery, specifically because things
> move around too much.

That can be handled. It calls for using a volume name or UUID on file
systems and allowing mount to accept the volume name.

One way would be to add the volume identifier (whatever it ends up being)
to the /proc/partitions file. Then mount could search that table for
the volume name and use the associated device definitions to accomplish
the mount.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

^ permalink raw reply	[flat|nested] 95+ messages in thread
* Re: Larger dev_t
@ 2001-03-27  9:29 Andries.Brouwer
  2001-03-27 18:48 ` Linus Torvalds
  2001-03-27 19:27 ` Albert D. Cahalan
  0 siblings, 2 replies; 95+ messages in thread
From: Andries.Brouwer @ 2001-03-27  9:29 UTC (permalink / raw)
  To: Andries.Brouwer, torvalds; +Cc: alan, hpa, linux-kernel, tytso

> On Sun, 25 Mar 2001 Andries.Brouwer@cwi.nl 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 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 libc5.

In kernel space we all want to use pointers to a device struct,
and major and minor are fields in that struct. There is no advantage
in making those fields narrow. And what is carried around is the
pointer, a 32-bit object.

In other words, inside the kernel the normal obvious coding will
give us ints major, minor. Outside the kernel we have a 64-bit dev_t.
And there is only the interface of system calls that uses this
narrow 16-bit straw. Of course, making it 32-bit is an improvement
but I can really not see any reason to make things difficult for
ourselves by widening this straw to 32-bits only.
Changing kernel and filesystems and glibc is a bit of a hassle -
not very difficult, but we started six years ago and still have
not finished - so it is better to do things right at once.


> It's equally true that changing "pid_t" will require that you recompile
> every single app that might have a kernel interface to the current 32-bit
> pid_t.

It was an example showing the advantage of having a 64-bit object.
Code gets simpler and faster.
But while dev_t already is 64-bits in user space, the same does not
hold for pid_t. I think that I once sent you a patch that would make
the pid use 2^31 instead of 2^15 values. Changing the size of pid_t
is not really possible, it would require a new version of the glibc
library.

	In short, both your arguments are totally bogus. Your "simpler" function
	is in fact a horrible rats nest and a source of subtle bugs that you
	apparently never even thought about.

	And that's without ever actually mentioning the word "bloat" and "data
	cache usage".

Not so pessimistic. Think and reconsider.

Andries




^ permalink raw reply	[flat|nested] 95+ messages in thread
* Re: Larger dev_t
@ 2001-03-26 21:18 John Byrne
  2001-03-26 22:12 ` Linus Torvalds
  2001-03-26 23:41 ` Guest section DW
  0 siblings, 2 replies; 95+ messages in thread
From: John Byrne @ 2001-03-26 21:18 UTC (permalink / raw)
  To: torvalds; +Cc: linux-kernel

> Re: Larger dev_t
> 
On Sat Mar 24 2001 Linus Torvalds (torvalds@transmeta.com) 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 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 number should probably be derived in some other manner
such as a library or system call. Code that determines device type by
comparing with the major/minor numbers should probably be discouraged in
the long run and this could be a good time to start.

John Byrne

^ permalink raw reply	[flat|nested] 95+ messages in thread
* Re: Larger dev_t
@ 2001-03-25 12:31 Andries.Brouwer
  2001-03-25 15:35 ` Wichert Akkerman
                   ` (2 more replies)
  0 siblings, 3 replies; 95+ messages in thread
From: Andries.Brouwer @ 2001-03-25 12:31 UTC (permalink / raw)
  To: Andries.Brouwer, torvalds; +Cc: alan, hpa, linux-kernel, tytso

    From torvalds@transmeta.com Sun Mar 25 05:26:51 2001

    On Sat, 24 Mar 2001 Andries.Brouwer@cwi.nl 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
    possible?

    Not a very strong argument.

    There is no way in HELL I will ever accept a 64-bit dev_t.

    I don't care one _whit_ about the fact that Ulrich Drepper thinks that
    it's a good idea to make things too large.

Funny.

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 = 0x10000000000ULL;

kdev_t get_unnamed_dev(void) {
        return to_kdev_t(next_unnamed_device++);
}

void put_unnamed_dev(kdev_t dev) {
}

a large name space allows one to omit checking what part can be
reused - reuse is unnecessary. That is also why I use a 64-bit pid:
upon a fork one does not have to search for pids, pgrps, sessions
with a given pid, and getpid() can be

static int get_pid(unsigned long flags) {
	if (flags & CLONE_PID)
		return current->pid;
	spin_lock(&lastpid_lock);
	++last_pid;
	spin_unlock(&lastpid_lock);
	return last_pid;
}

fast, simple, avoiding obscure security problems.
Yes, a large name space makes life simpler.

Now concerning this dev_t:
Outside the kernel we have glibc and it is 64 bits.
Inside the kernel we have a pointer to a device struct.
The kernel idea of the size of dev_t only plays a role
on the system call interface.

Really, I see no advantages at all restricting the interface
to something smaller than what user space and kernel use.
And saying "12 bits is enough for a major" somehow sounds funny.

Andries

^ permalink raw reply	[flat|nested] 95+ messages in thread
* Re: Larger dev_t
@ 2001-03-24 16:13 Andries.Brouwer
  0 siblings, 0 replies; 95+ messages in thread
From: Andries.Brouwer @ 2001-03-24 16:13 UTC (permalink / raw)
  To: Andries.Brouwer, jgarzik; +Cc: alan, hpa, linux-kernel, torvalds, tytso, viro

> 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 approaches.

The stuff I sent earlier today was the dev_t part.
The next part I hope to send one of these days is the
interface between dev_t and kdev_t.
(Most people think that kdev_t is an integer, I think that
it is a pointer. Since dev_t now can be large and arrays
cannot be used, we need some hash lookup to find the
structure corresponding to the number. And the code is
roughly speaking identical to Al's bdev code, only now used
both for bdev and cdev.)

(Funny enough Al's code does not solve the only small problem
I had six years ago: a mknod with funny numbers does not mean
that some such device actually exists. In reality we only
want to convert number into device pointer when the device is
opened, but the current kernel code does
	init_special_inode(inode, mode, rdev);
for a mknod, and if it was a block device
	inode->i_bdev = bdget(rdev);
so that it does allocate a struct to this nonsense device.)

Andries

^ permalink raw reply	[flat|nested] 95+ messages in thread
* Larger dev_t
@ 2001-03-24 14:25 Andries.Brouwer
  2001-03-24 14:40 ` Jeff Garzik
  2001-03-25  3:24 ` Linus Torvalds
  0 siblings, 2 replies; 95+ messages in thread
From: Andries.Brouwer @ 2001-03-24 14:25 UTC (permalink / raw)
  To: alan, hpa, torvalds, tytso; +Cc: linux-kernel

Dear Linus and all,

One of these days we must change dev_t.

There are several aspects to this, but this letter touches
only the kernel-*libc interface.

We need a size, and I am strongly in favor of sizeof(dev_t) = 8;
this is already true in glibc.

The two main uses of dev_t are in struct stat and as parameter
of the mknod system call. There are a few other occurrences,
such as ustat() and the use of dev_t as a field in struct loopinfo
returned by some ioctl.
- For stat all is fine already since we got stat64.
- For mknod a little work is required.
- The state of affairs with loopinfo is sad today (the fact that
kernel and glibc use dev_t of different size causes problems)
but all will be well with 64-bit dev_t.
- With ustat the converse is true. Of course it is obsolete,
but with 64-bit dev_t we are forced to throw it out - libc5
has xustat just like xstat and xmknod, but glibc hasn't so it
is not easy to save it. There are still some programs that use it:
in CD players to test (before eject) whether a CD is mounted;
in various programs such as sendmail and uucp to test how much
free space we have.
So, glibc will have to return EINVAL (or EOVERFLOW) here
for device numbers that actually use more than 16 bits.

The transformation from 64 bits to pair (major,minor) is
                if ((major = (dev >> 32)) != 0)
                        minor = (dev & 0xffffffff);
                else if ((major = (dev >> 16)) != 0)
                        minor = (dev & 0xffff);
                else {
                        major = (dev >> 8);
                        minor = (dev & 0xff);
                }
This means that old device numbers remain valid.

The stuff below describes a working interface where 64-bit values
are passed to and from the kernel, and to and from the filesystem.
That is, it is dev_t stuff. Some other time on kernel-internal matters,
that is, kdev_t stuff.

Details of my setup of today (with 64-bit dev_t):
(i) ext2:

diff -r linux-2.4.2/linux/fs/ext2/inode.c linux-2.4.2kdevt/linux/fs/ext2/inode.c
1076,1078c1076,1081
<       } else 
<               init_special_inode(inode, inode->i_mode,
<                                  le32_to_cpu(raw_inode->i_block[0]));
---
>       } else {
>               unsigned int lo = le32_to_cpu(raw_inode->i_block[0]);
>               unsigned int hi = le32_to_cpu(raw_inode->i_block[1]);
>               dev_t devno = ((unsigned long long) hi << 32) | lo;
>               init_special_inode(inode, inode->i_mode, devno);
>       }
1211,1213c1214,1221
<       if (S_ISCHR(inode->i_mode) || S_ISBLK(inode->i_mode))
<               raw_inode->i_block[0] = cpu_to_le32(kdev_t_to_nr(inode->i_rdev))
;
<       else for (block = 0; block < EXT2_N_BLOCKS; block++)
---
>       if (S_ISCHR(inode->i_mode) || S_ISBLK(inode->i_mode)) {
>               /* we use that EXT2_N_BLOCKS > 1 */
>               dev_t devno = kdev_t_to_nr(inode->i_rdev);
>               unsigned int hi = (devno >> 32);
>               unsigned int lo = (devno & 0xffffffff);
>               raw_inode->i_block[0] = cpu_to_le32(lo);
>               raw_inode->i_block[1] = cpu_to_le32(hi);
>       } else for (block = 0; block < EXT2_N_BLOCKS; block++)

Ted, please complain if I am mistaken in thinking that
raw_inode->i_block[1] can be used.
There is a minor conversion problem here: there is no guarantee
that raw_inode->i_block[1] will be zero in old systems.


(ii) vfs:

diff -r linux-2.4.2/linux/fs/devices.c linux-2.4.2kdevt/linux/fs/devices.c
200c200
< void init_special_inode(struct inode *inode, umode_t mode, int rdev)
---
> void init_special_inode(struct inode *inode, umode_t mode, dev_t rdev)

(iii) mknod:
Then there is the prototype of mknod.
I changed it for all filesystems to

diff -r linux-2.4.2/linux/fs/ext2/namei.c linux-2.4.2kdevt/linux/fs/ext2/namei.c
387c387,388
< static int ext2_mknod (struct inode * dir, struct dentry *dentry, int mode, int rdev)
---
> static int ext2_mknod (struct inode * dir, struct dentry *dentry, int mode,
>                      dev_t rdev)

The system call itself cannot easily be changed to take a larger dev_t,
mostly because under old glibc the high order part would be random.
So, mknod64, with

diff linux-2.4.2/linux/fs/namei.c linux-2.4.2kdevt/linux/fs/namei.c
1205c1208
< asmlinkage long sys_mknod(const char * filename, int mode, dev_t dev)
---
> static long mknod_common(const char * filename, int mode, dev_t dev)
1245a1249,1259
> }
> 
> asmlinkage long sys_mknod64(const char * filename, int mode,
>                           unsigned int ma, unsigned int mi)
> {
>       return mknod_common(filename, mode, ((dev_t) ma << 32) | mi);
> }
> 
> asmlinkage long sys_mknod(const char * filename, int mode, unsigned short dev)
> {
>       return mknod_common(filename, mode, dev);

and __NR_mknod64 in unistd.h and .long SYMBOL_NAME(sys_mknod64) in entry.S.

Changes to glibc2:

--- glibc-2.2.1/sysdeps/unix/sysv/linux/xmknod.c        Fri Jul  7 19:57:38 2000
+++ glibc-2.2.1mk/sysdeps/unix/sysv/linux/xmknod.c      Sat Mar 24 13:53:50 2001
@@ -29,6 +29,13 @@
 extern int __syscall_mknod (const char *__unbounded, unsigned short int,
                            unsigned short int);
 
+extern int __syscall_mknod64 (const char *__unbounded, unsigned short int,
+                           dev_t);
+
+#ifndef __NR_mknod64
+#define __NR_mknod64            223
+#endif
+
 /* Create a device file named PATH, with permission and special bits MODE
    and device number DEV (which can be constructed from major and minor
    device numbers with the `makedev' macro above).  */
@@ -36,6 +43,7 @@
 __xmknod (int vers, const char *path, mode_t mode, dev_t *dev)
 {
   unsigned short int k_dev;
+  unsigned int ma, mi;
 
   if (vers != _MKNOD_VER)
     {
@@ -43,9 +51,17 @@
       return -1;
     }
 
+  if ((*dev >> 16) != 0)
+    {
+      /* need mknod64 */  
+      /* pass the 64-bit arg as two 32-bit integers (le) */
+      ma = ((*dev) >> 32);
+      mi = ((*dev) & 0xffffffff);
+      return INLINE_SYSCALL (mknod64, 4, CHECK_STRING (path), mode, ma, mi);
+    }
+  
   /* We must convert the value to dev_t type used by the kernel.  */
   k_dev = ((major (*dev) & 0xff) << 8) | (minor (*dev) & 0xff);
-
   return INLINE_SYSCALL (mknod, 3, CHECK_STRING (path), mode, k_dev);
 }

I almost submitted this as an actual patch, but it changes vfs
prototypes, and probably that is against the rules during a stable series.
If something in this style is OK I'll make a patch as soon as 2.5
is started.

Andries

[the above is running on the machine I send this mail from]

^ permalink raw reply	[flat|nested] 95+ messages in thread
end of thread, other threads:[~2001-04-04  8:10 UTC | newest]

Thread overview: 95+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-04-02 20:17 Larger dev_t Andries.Brouwer
2001-04-02 21:45 ` Alan Cox
2001-04-03  7:28 ` Martin Dalecki
2001-04-03 10:09 ` Ingo Oeser
2001-04-03 12:06   ` Alan Cox
2001-04-03 12:20     ` Ingo Oeser
2001-04-03 12:15       ` Martin Dalecki
2001-04-03 12:53         ` Alan Cox
2001-04-03 16:05           ` Richard Gooch
2001-04-03 16:34             ` Alexander Viro
2001-04-03 16:58               ` Richard Gooch
2001-04-03 16:54             ` Alan Cox
2001-04-03 17:02               ` Richard Gooch
2001-04-03 12:41       ` Alan Cox
2001-04-03 23:28       ` Tim Wright
  -- strict thread matches above, loose matches on Subject: below --
2001-04-03 14:48 Wayne.Brown
2001-04-03 15:34 ` Bart Trojanowski
2001-04-02 21:59 Andries.Brouwer
2001-03-27 22:38 Jesse Pollard
2001-03-27 22:44 ` H. Peter Anvin
2001-03-27  9:29 Andries.Brouwer
2001-03-27 18:48 ` Linus Torvalds
2001-03-27 19:28   ` H. Peter Anvin
2001-03-27 19:51     ` Linus Torvalds
2001-03-27 21:21       ` Alan Cox
2001-03-27 21:35         ` Linus Torvalds
2001-03-27 22:02           ` Andre Hedrick
2001-03-27 23:57             ` Linus Torvalds
2001-03-28 21:23               ` Martin Dalecki
2001-03-28 21:40                 ` H. Peter Anvin
2001-03-28 21:44                 ` Andre Hedrick
2001-03-27 22:16           ` Alan Cox
2001-03-27 22:16             ` H. Peter Anvin
2001-03-27 22:43               ` Russell King
2001-03-28 16:59                 ` Jeff Randall
2001-03-28  0:07             ` Linus Torvalds
2001-03-28  0:10               ` H. Peter Anvin
2001-03-28  0:24                 ` Linus Torvalds
2001-03-28  2:19               ` Alan Cox
2001-03-28  7:08                 ` Andre Hedrick
2001-03-28 21:32                 ` Martin Dalecki
2001-03-29  3:53                   ` Alan Cox
2001-03-29 11:02                     ` Martin Dalecki
2001-04-02 20:02                       ` Alan Cox
2001-04-03  7:25                         ` Martin Dalecki
2001-04-03 12:19                           ` Alan Cox
2001-04-03 12:13                             ` Martin Dalecki
2001-04-03 12:38                               ` Alan Cox
2001-04-04  8:08                                 ` Rogier Wolff
2001-03-30  6:54                   ` Kai Henningsen
2001-03-28 21:18             ` Martin Dalecki
2001-03-27 22:13         ` H. Peter Anvin
2001-03-27 22:55           ` Dan Hollis
2001-03-27 22:58             ` H. Peter Anvin
2001-03-27 23:42               ` Richard Gooch
2001-03-28  1:03             ` Paul Jakma
2001-03-28  1:35               ` Alexander Viro
2001-03-27 23:44           ` Andrew Pimlott
2001-03-28  0:28             ` Albert D. Cahalan
2001-03-28  3:58           ` Johan Kullstam
2001-03-28  4:23             ` Alexander Viro
2001-03-28 11:57             ` Jesse Pollard
2001-03-28 18:13               ` Oliver Neukum
2001-03-28 19:05                 ` Jesse Pollard
2001-03-28 19:50                   ` Oliver Neukum
2001-03-28 21:36             ` Martin Dalecki
2001-03-28 21:09           ` Martin Dalecki
2001-03-28 21:24             ` H. Peter Anvin
2001-03-28 21:46               ` Alexander Viro
2001-03-28 20:54     ` Martin Dalecki
2001-03-28 11:52   ` Pjotr Kourzanoff
2001-03-28 12:11   ` Tim Jansen
2001-03-27 19:27 ` Albert D. Cahalan
2001-03-26 21:18 John Byrne
2001-03-26 22:12 ` Linus Torvalds
2001-03-26 23:41 ` Guest section DW
2001-03-25 12:31 Andries.Brouwer
2001-03-25 15:35 ` Wichert Akkerman
2001-03-25 16:15   ` Mitchell Blank Jr
2001-03-25 16:54     ` Michel Wilson
2001-03-25 17:12       ` Jeff Garzik
2001-03-25 17:00     ` Jamie Lokier
2001-03-25 17:07     ` Anton Altaparmakov
2001-03-25 17:37       ` Michel Wilson
2001-03-25 18:21   ` Guest section DW
2001-03-25 20:50     ` diego
2001-03-25 17:55 ` Gerry
2001-03-27  6:03 ` Linus Torvalds
2001-03-24 16:13 Andries.Brouwer
2001-03-24 14:25 Andries.Brouwer
2001-03-24 14:40 ` Jeff Garzik
2001-03-24 15:00   ` Alexander Viro
2001-03-25 14:22   ` Martin Dalecki
2001-03-25  3:24 ` Linus Torvalds
2001-03-25 14:35   ` Martin Dalecki

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox