Re: more git updates..

[Kai Henningsen]

[EMAIL PROTECTED] (H. Peter Anvin)  wrote on 11.04.05 in <[EMAIL PROTECTED]>:

> Followup to:  <[EMAIL PROTECTED]>
> By author:Christopher Li <[EMAIL PROTECTED]>
> In newsgroup: linux.dev.kernel
> >
> > There is one problem though. How about the SHA1 hash collision?
> > Even the chance is very remote, you don't want to lose some data do due
> > to "software" error. I think it is OK that no handle that
> > case right now. On the other hand, it will be nice to detect that
> > and give out a big error message if it really happens.
> >
>
> If you're actually worried about it, it'd be better to just use a
> different hash, like one of the SHA-2's (probably a better choice
> anyway), instead of SHA-1.

How could that help? *Every* hash has hash collisions. It's an unavoidable  
result of using less bits than the original data has.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: more git updates..

[Kai Henningsen]

[EMAIL PROTECTED] (H. Peter Anvin)  wrote on 11.04.05 in [EMAIL PROTECTED]:

 Followup to:  [EMAIL PROTECTED]
 By author:Christopher Li [EMAIL PROTECTED]
 In newsgroup: linux.dev.kernel
 
  There is one problem though. How about the SHA1 hash collision?
  Even the chance is very remote, you don't want to lose some data do due
  to software error. I think it is OK that no handle that
  case right now. On the other hand, it will be nice to detect that
  and give out a big error message if it really happens.
 

 If you're actually worried about it, it'd be better to just use a
 different hash, like one of the SHA-2's (probably a better choice
 anyway), instead of SHA-1.

How could that help? *Every* hash has hash collisions. It's an unavoidable  
result of using less bits than the original data has.

MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Cosmetic JFFS patch.

[Kai Henningsen]

[EMAIL PROTECTED] (Torrey Hoffman)  wrote on 30.06.01 in 
<[EMAIL PROTECTED]>:

> So they compile it into the linux_logo.h image. It's now under the
> GPL, of course... what does that do to the legal status of the logo?

Copyright: you named it.

Any other right: unchanged. (The GPL doesn't demand any change, so how  
could it possibly change?)

However, for rights you want to keep, I'd suggest pointing them out in  
some sort of readme in the sources. ("The XXX Logo is a registered  
trademark of XXX Websites, Inc.".)

Frankly, in the context of (say) a registered trademark, the GPL for the  
logo becomes fairly meaningless ... sure, you can get "the source", but  
you can't *use* it except in those cases where you'd get "the source" for  
a proprietary logo anyway, unless it's a really weird case.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Cosmetic JFFS patch.

[Kai Henningsen]

[EMAIL PROTECTED] (Chuck Wolber)  wrote on 29.06.01 in 
<[EMAIL PROTECTED]>:

> > Does sed tell you who programmed it on startup?
> >
> > Awk?
> >
> > Perl?
> >
> > Groff?
> >
> > Gcc?
> >
> > See a pattern here?
>
> Yeah, the output of these programms are usually parsed by other programs.

s/usually/sometimes/

Most of the time, it's only parsed by humans, with the possible exception  
of awk.

But feel free to look for other common Unix programs that behave  
differently. df, du, ps, ls, bash ... there *are* programs that announce  
the copyright at the start, but there are damned few of them. It's not in  
the culture.

> If they barked version info, that'd be extra code that has to go into
> *EVERY* script that uses them. You're not using the kernel in the same
> capacity.

OTOH, kernel output typically *always* goes into another program (dmesg,  
klog, syslog) ... though admittedly parsing it is not common. Well, except  
for the oops part (klogd, ksymoops).

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Cosmetic JFFS patch.

[Kai Henningsen]

[EMAIL PROTECTED] (Torrey Hoffman)  wrote on 30.06.01 in 
[EMAIL PROTECTED]:

 So they compile it into the linux_logo.h image. It's now under the
 GPL, of course... what does that do to the legal status of the logo?

Copyright: you named it.

Any other right: unchanged. (The GPL doesn't demand any change, so how  
could it possibly change?)

However, for rights you want to keep, I'd suggest pointing them out in  
some sort of readme in the sources. (The XXX Logo is a registered  
trademark of XXX Websites, Inc..)

Frankly, in the context of (say) a registered trademark, the GPL for the  
logo becomes fairly meaningless ... sure, you can get the source, but  
you can't *use* it except in those cases where you'd get the source for  
a proprietary logo anyway, unless it's a really weird case.

MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Cosmetic JFFS patch.

[Kai Henningsen]

[EMAIL PROTECTED] (Chuck Wolber)  wrote on 29.06.01 in 
[EMAIL PROTECTED]:

  Does sed tell you who programmed it on startup?
 
  Awk?
 
  Perl?
 
  Groff?
 
  Gcc?
 
  See a pattern here?

 Yeah, the output of these programms are usually parsed by other programs.

s/usually/sometimes/

Most of the time, it's only parsed by humans, with the possible exception  
of awk.

But feel free to look for other common Unix programs that behave  
differently. df, du, ps, ls, bash ... there *are* programs that announce  
the copyright at the start, but there are damned few of them. It's not in  
the culture.

 If they barked version info, that'd be extra code that has to go into
 *EVERY* script that uses them. You're not using the kernel in the same
 capacity.

OTOH, kernel output typically *always* goes into another program (dmesg,  
klog, syslog) ... though admittedly parsing it is not common. Well, except  
for the oops part (klogd, ksymoops).

MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Cosmetic JFFS patch.

[Kai Henningsen]

[EMAIL PROTECTED]  wrote on 28.06.01 in 
<[EMAIL PROTECTED]>:

> > > Linux NET4.0 for Linux 2.4
> > > Based upon Swansea University Computer Society NET3.039
> >
> > The later line is not something of interest to most people, and if it
> > happens to be they can research it rather than being force-fed history
> > on bootup.
>
> I've never met a single person who shared that opinion. In fact, quite the
> contrary. It's the main source of currency in this space. If you can't
> toot your own horn and/or share credit what's all of this open source
> stuff worth? We aren't all Mother Theresa now...

Does sed tell you who programmed it on startup?

Awk?

Perl?

Groff?

Gcc?

See a pattern here?

I might add that the most-used program I was one of several authors of  
*never* mentioned a single author in the program messages, with the single  
exception that the initials of the author actually compiling the source  
were part of the version string (in an attempt to control "just which  
patch to 7.53 are you talking about?" syndrome). I can't say this ever  
bothered me.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Cosmetic JFFS patch.

[Kai Henningsen]

[EMAIL PROTECTED] (Linus Torvalds)  wrote on 28.06.01 in 
<[EMAIL PROTECTED]>:

> On Thu, 28 Jun 2001, David Woodhouse wrote:
> >
> > I agree the messages can be ugly. But they don't do any harm either, and
> > sometimes they're useful.
>
> I consider them harmful when I start getting annoying patches that start
> adding more and more of them.

Or when there are enough boot messages that the dmesg buffer overflows. My  
current (2.2.19pre1 or so) system has that problem.

That *is* harm caused by these messages.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] User chroot

[Kai Henningsen]

[EMAIL PROTECTED] (H. Peter Anvin)  wrote on 27.06.01 in 
<9hd7pl$86f$[EMAIL PROTECTED]>:

> By author:[EMAIL PROTECTED] (Kai Henningsen)

> > [EMAIL PROTECTED] (Jorgen Cederlof)  wrote on 27.06.01 in
> > <20010627014534.B2654@ondska>:
> >
> > > If we only allow user chroots for processes that have never been
> > > chrooted before, and if the suid/sgid bits won't have any effect under
> > > the new root, it should be perfectly safe to allow any user to chroot.
> >
> > Hmm. Dos this work with initrd and root pivoting?
> >
>
> At the moment, yes.  Once Viro gets his root-changes in, this breaks,
> since ALL processes will be chrooted.

About what I expected. So you'd really want this flag to be resettable by  
root, if you go that way at all. Beginning to look a little too compley, I  
think.

The last time, ISTR we discussed some other, similar-but-different  
syscalls that made for more secure jails. I don't quite remember the  
details, though.


MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] User chroot

[Kai Henningsen]

[EMAIL PROTECTED] (H. Peter Anvin)  wrote on 27.06.01 in 
9hd7pl$86f$[EMAIL PROTECTED]:

 By author:[EMAIL PROTECTED] (Kai Henningsen)

  [EMAIL PROTECTED] (Jorgen Cederlof)  wrote on 27.06.01 in
  20010627014534.B2654@ondska:
 
   If we only allow user chroots for processes that have never been
   chrooted before, and if the suid/sgid bits won't have any effect under
   the new root, it should be perfectly safe to allow any user to chroot.
 
  Hmm. Dos this work with initrd and root pivoting?
 

 At the moment, yes.  Once Viro gets his root-changes in, this breaks,
 since ALL processes will be chrooted.

About what I expected. So you'd really want this flag to be resettable by  
root, if you go that way at all. Beginning to look a little too compley, I  
think.

The last time, ISTR we discussed some other, similar-but-different  
syscalls that made for more secure jails. I don't quite remember the  
details, though.


MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Cosmetic JFFS patch.

[Kai Henningsen]

[EMAIL PROTECTED]  wrote on 28.06.01 in 
[EMAIL PROTECTED]:

   Linux NET4.0 for Linux 2.4
   Based upon Swansea University Computer Society NET3.039
 
  The later line is not something of interest to most people, and if it
  happens to be they can research it rather than being force-fed history
  on bootup.

 I've never met a single person who shared that opinion. In fact, quite the
 contrary. It's the main source of currency in this space. If you can't
 toot your own horn and/or share credit what's all of this open source
 stuff worth? We aren't all Mother Theresa now...

Does sed tell you who programmed it on startup?

Awk?

Perl?

Groff?

Gcc?

See a pattern here?

I might add that the most-used program I was one of several authors of  
*never* mentioned a single author in the program messages, with the single  
exception that the initials of the author actually compiling the source  
were part of the version string (in an attempt to control just which  
patch to 7.53 are you talking about? syndrome). I can't say this ever  
bothered me.

MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Cosmetic JFFS patch.

[Kai Henningsen]

[EMAIL PROTECTED] (Linus Torvalds)  wrote on 28.06.01 in 
[EMAIL PROTECTED]:

 On Thu, 28 Jun 2001, David Woodhouse wrote:
 
  I agree the messages can be ugly. But they don't do any harm either, and
  sometimes they're useful.

 I consider them harmful when I start getting annoying patches that start
 adding more and more of them.

Or when there are enough boot messages that the dmesg buffer overflows. My  
current (2.2.19pre1 or so) system has that problem.

That *is* harm caused by these messages.

MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] User chroot

[Kai Henningsen]

[EMAIL PROTECTED] (H. Peter Anvin)  wrote on 26.06.01 in <[EMAIL PROTECTED]>:

> Albert D. Cahalan wrote:
>
> >
> > Normal users can use an environment provided for them.
> >
> > While trying to figure out why the "heyu" program would not
> > work on a Red Hat box, I did just this. As root I set up all
> > the device files needed, along Debian libraries and the heyu
> > executable itself. It was annoying that I couldn't try out
> > my chroot environment as a regular user.
> >
> > Creating the device files isn't a big deal. It wouldn't be
> > hard to write a setuid app to make the few needed devices.
> > If we had per-user limits, "mount --bind /dev/zero /foo/zero"
> > could be allowed. One way or another, devices can be provided.
> >
>
>
> Hell no!  This would give the user a way to subvert root or other
> system-provided things by having device nodes or such appear where they
> aren't expected.  NOT GOOD.

Well, only allow them where you expect them then. That's easy enough.


MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] User chroot

[Kai Henningsen]

[EMAIL PROTECTED] (Jorgen Cederlof)  wrote on 27.06.01 in 
<20010627014534.B2654@ondska>:

> If we only allow user chroots for processes that have never been
> chrooted before, and if the suid/sgid bits won't have any effect under
> the new root, it should be perfectly safe to allow any user to chroot.

Hmm. Dos this work with initrd and root pivoting?

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] User chroot

[Kai Henningsen]

[EMAIL PROTECTED] (H. Peter Anvin)  wrote on 26.06.01 in [EMAIL PROTECTED]:

 Albert D. Cahalan wrote:

 
  Normal users can use an environment provided for them.
 
  While trying to figure out why the heyu program would not
  work on a Red Hat box, I did just this. As root I set up all
  the device files needed, along Debian libraries and the heyu
  executable itself. It was annoying that I couldn't try out
  my chroot environment as a regular user.
 
  Creating the device files isn't a big deal. It wouldn't be
  hard to write a setuid app to make the few needed devices.
  If we had per-user limits, mount --bind /dev/zero /foo/zero
  could be allowed. One way or another, devices can be provided.
 


 Hell no!  This would give the user a way to subvert root or other
 system-provided things by having device nodes or such appear where they
 aren't expected.  NOT GOOD.

Well, only allow them where you expect them then. That's easy enough.


MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] User chroot

[Kai Henningsen]

[EMAIL PROTECTED] (Jorgen Cederlof)  wrote on 27.06.01 in 
20010627014534.B2654@ondska:

 If we only allow user chroots for processes that have never been
 chrooted before, and if the suid/sgid bits won't have any effect under
 the new root, it should be perfectly safe to allow any user to chroot.

Hmm. Dos this work with initrd and root pivoting?

MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Microsoft and Xenix.

[Kai Henningsen]

[EMAIL PROTECTED] (Rob Landley)  wrote on 24.06.01 in 
<[EMAIL PROTECTED]>:

> Now if somebody here could just point me to a decent reference on A/UX -
> Apple's mid-80's version of Unix (for the early macintosh, I believe...)

http://www.google.com/search?q=%22%2ba/ux%22

Usually a good idea.



Also, you probably want to look at RFC 2235.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Microsoft and Xenix.

[Kai Henningsen]

[EMAIL PROTECTED] (Rob Landley)  wrote on 23.06.01 in 
<[EMAIL PROTECTED]>:

> on April 2, 1987.  (models 50, 60, and 80.)  The SAA/SNA push also extended
> through the System/370 and AS400 stuff too.  (I think 370's the mainframe
> and AS400 is the minicomputer, but I'd have to look it up.  One of them
> (AS400?) had a database built into the OS.  Interestingly, this is where SQL
> originated (my notes say SQL came from the System/370 but I have to
> double-check that, I thought the AS400 was the one with the built in
> database?).

The AS/400 is still going strong. It's a virtual machine based on a  
relational database (among other things), mostly programmed in COBOL (I  
think the C compiler has sizeof(void*) == 16 or something like that, so  
you can put a database position in that pointer), it doesn't know the  
difference between disk and memory (memory is *really* only a cache), and  
these days it's usually running on PowerPC hardware.

ISTR there's a gcc port for the AS/400. Oh, and it does have normal BSD  
Sockets. These days, it's often sold as a web server.

Main customer base seems to be medium large businesses and banks.

> Lotus-Intel-Microsoft Expanded Memory Specification), and "DOSShell" which
> conformed to the SAA graphical user interface guidelines.

Nope, the text user interface guidelines, a related but not the same  
beast. That's where F1 == Help is from, by the way.

In fact, the user interface part of SAA was (is?) called CUA. And many IBM  
text mode interfaces more or less follow it, including OS/400 (the os of  
the AS/400). Once upon a time, I had the specs for CUA.

> The PS/2 model 70/80 (desktop/tower versions of same thing) were IBM's first
> 386 based PC boxes, which came with either DOS 3.3, DOS 4.0, OS/2 (1.0), or
> AIX.

The first 386 PCs where not from IBM, by the way. Was it Compaq?

> AIX was NOT fully SAA/SNA compliant,

AFAICT, nothing ever was fully SAA compliant, though some systems were  
more compliant than others.

> Hmmm...  Notes on the history of shareware (pc-write/bob wallace/quiicksoft,
> pc-file/pc-calc/jim button/buttonware, pc-talk/andrew flugelman, apparently
> the chronological order is andrew-jim-bob, and bob came up with the name
> "shareware" because "freeware" was a trademark of Headlands Press, Inc...)

That may be, but I believe the *concept* was invented in 1980 by Bill  
Basham, with the Apple ][ DOS replacement Diversi-DOS (which was the most  
popular of many versions to increase disk speed by about a factor of 5). I  
still remember discussions how copying this stuff was actually the right  
thing to do. Seems he's still in business as "Diversified Software  
Research", http://www.divtune.com/.

> running AIX.  The engineers (in Austin) whent on for the second generation
> Risc System 6000 (the RS/6000) with AIX version 3, launched February 15
> 1990. The acronym "POWER" stands for Performance Optimized WIth Enhanced
> Risc.

The PowerPC was split off from the POWER architecture, and then the POWER  
stuff was turned into the high end above PowerPC (with system prices about  
a factor of ten higher as the lower bound).

IBM developed a version of OS/2 2.0 for the PowerPC, but *never* marketed  
it - you could buy it if you knew the right number, but they never spent a  
single cent on advertizing - by the time it was done, IBM had given up on  
OS/2. Most OS/2 fans agreed that it was killed by IBM with extremely bad  
marketing.

These days, of course Apple builds the most PowerPC machines; Motorola and  
IBM produce the chips.

> Ummm...  GEM was the Geos stuff?

No. GEM, I believe, originally came from CP/M. Most popular as the  
windowing system of the Atari ST; given that someone did a quick-hack MS- 
DOS clone to support it on the 68K, it seems fairly obvious that by that  
time, it had already been ported to MS-DOS. (GEM-DOS is the only os I know  
of that was actually worse than MS-DOS.)

Friends of mine (Gereon Steffens and Stefan Eissing) wrote a command-line  
shell and desktop replacement for the Atari that was fairly successful  
shareware for a while ... now how was it called? The CLI was Mupfel  
(German for shell is Muschel, and there was a kid's TV character who  
pronounced Muschel as Mupfel), and I think the desktop was Gemini. Another  
(Julian Reschke) wrote *the* German Atari ST book. This was a fairly  
prominent Atari ST area for a while, but somehow I never had one.

> Using 3d accelerator cards to play MPEG video streams is only now becoming
> feasable to do under X.  And it SHOULD be possible to do that through a
> 100baseT network, let alone gigabit, but the layering's all wrong...)

One might say it's time for X12, except the installed base of X11 has  
become too large.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  

Re: Microsoft and Xenix.

[Kai Henningsen]

[EMAIL PROTECTED] (Rob Landley)  wrote on 23.06.01 in 
[EMAIL PROTECTED]:

 on April 2, 1987.  (models 50, 60, and 80.)  The SAA/SNA push also extended
 through the System/370 and AS400 stuff too.  (I think 370's the mainframe
 and AS400 is the minicomputer, but I'd have to look it up.  One of them
 (AS400?) had a database built into the OS.  Interestingly, this is where SQL
 originated (my notes say SQL came from the System/370 but I have to
 double-check that, I thought the AS400 was the one with the built in
 database?).

The AS/400 is still going strong. It's a virtual machine based on a  
relational database (among other things), mostly programmed in COBOL (I  
think the C compiler has sizeof(void*) == 16 or something like that, so  
you can put a database position in that pointer), it doesn't know the  
difference between disk and memory (memory is *really* only a cache), and  
these days it's usually running on PowerPC hardware.

ISTR there's a gcc port for the AS/400. Oh, and it does have normal BSD  
Sockets. These days, it's often sold as a web server.

Main customer base seems to be medium large businesses and banks.

 Lotus-Intel-Microsoft Expanded Memory Specification), and DOSShell which
 conformed to the SAA graphical user interface guidelines.

Nope, the text user interface guidelines, a related but not the same  
beast. That's where F1 == Help is from, by the way.

In fact, the user interface part of SAA was (is?) called CUA. And many IBM  
text mode interfaces more or less follow it, including OS/400 (the os of  
the AS/400). Once upon a time, I had the specs for CUA.

 The PS/2 model 70/80 (desktop/tower versions of same thing) were IBM's first
 386 based PC boxes, which came with either DOS 3.3, DOS 4.0, OS/2 (1.0), or
 AIX.

The first 386 PCs where not from IBM, by the way. Was it Compaq?

 AIX was NOT fully SAA/SNA compliant,

AFAICT, nothing ever was fully SAA compliant, though some systems were  
more compliant than others.

 Hmmm...  Notes on the history of shareware (pc-write/bob wallace/quiicksoft,
 pc-file/pc-calc/jim button/buttonware, pc-talk/andrew flugelman, apparently
 the chronological order is andrew-jim-bob, and bob came up with the name
 shareware because freeware was a trademark of Headlands Press, Inc...)

That may be, but I believe the *concept* was invented in 1980 by Bill  
Basham, with the Apple ][ DOS replacement Diversi-DOS (which was the most  
popular of many versions to increase disk speed by about a factor of 5). I  
still remember discussions how copying this stuff was actually the right  
thing to do. Seems he's still in business as Diversified Software  
Research, http://www.divtune.com/.

 running AIX.  The engineers (in Austin) whent on for the second generation
 Risc System 6000 (the RS/6000) with AIX version 3, launched February 15
 1990. The acronym POWER stands for Performance Optimized WIth Enhanced
 Risc.

The PowerPC was split off from the POWER architecture, and then the POWER  
stuff was turned into the high end above PowerPC (with system prices about  
a factor of ten higher as the lower bound).

IBM developed a version of OS/2 2.0 for the PowerPC, but *never* marketed  
it - you could buy it if you knew the right number, but they never spent a  
single cent on advertizing - by the time it was done, IBM had given up on  
OS/2. Most OS/2 fans agreed that it was killed by IBM with extremely bad  
marketing.

These days, of course Apple builds the most PowerPC machines; Motorola and  
IBM produce the chips.

 Ummm...  GEM was the Geos stuff?

No. GEM, I believe, originally came from CP/M. Most popular as the  
windowing system of the Atari ST; given that someone did a quick-hack MS- 
DOS clone to support it on the 68K, it seems fairly obvious that by that  
time, it had already been ported to MS-DOS. (GEM-DOS is the only os I know  
of that was actually worse than MS-DOS.)

Friends of mine (Gereon Steffens and Stefan Eissing) wrote a command-line  
shell and desktop replacement for the Atari that was fairly successful  
shareware for a while ... now how was it called? The CLI was Mupfel  
(German for shell is Muschel, and there was a kid's TV character who  
pronounced Muschel as Mupfel), and I think the desktop was Gemini. Another  
(Julian Reschke) wrote *the* German Atari ST book. This was a fairly  
prominent Atari ST area for a while, but somehow I never had one.

 Using 3d accelerator cards to play MPEG video streams is only now becoming
 feasable to do under X.  And it SHOULD be possible to do that through a
 100baseT network, let alone gigabit, but the layering's all wrong...)

One might say it's time for X12, except the installed base of X11 has  
become too large.

MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Microsoft and Xenix.

[Kai Henningsen]

[EMAIL PROTECTED] (Rob Landley)  wrote on 24.06.01 in 
[EMAIL PROTECTED]:

 Now if somebody here could just point me to a decent reference on A/UX -
 Apple's mid-80's version of Unix (for the early macintosh, I believe...)

http://www.google.com/search?q=%22%2ba/ux%22

Usually a good idea.



Also, you probably want to look at RFC 2235.

MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: The latest Microsoft FUD. This time from BillG, himself.

[Kai Henningsen]

[EMAIL PROTECTED] (Rob Landley)  wrote on 22.06.01 in 
<[EMAIL PROTECTED]>:

> On Thursday 21 June 2001 18:49, Alan Cox wrote:
>
> > > Except that Apple keeps the old code open. Probably because
> > > they'll gain nothing from it, and at best, they can appeal to
> > > the techies.
> >
> > A company that seems to write 'you shall not work on open source projects
> > in your spare time' into its employment contracts is not what I would call
> > friendly or want to work for. Im sure its only a small step to 'employees
> > shall not snowboard' 'employees shall not go skiing' - all of course
> > argued for the same reason as being essential to the company interest
>
> This IS the company that had the "I work 90 hours all the time" club with
> t-shirts and everything back under Jobs in the early 80's.  And far more
> recently, where at least one employee got in trouble for "thinking
> different' with a parody site involving famous serial killers.
>
> The "Proprietary frosting" model is fine for leaf-node projects like games.
> But if the new layer is infrastructure other people are expected to build on
> top of, then what you're really saying is "I want slaves".

Hmm. This *is* the company that has at least one guy full-time working on  
merging their changes back into gcc (with the right Copyright  
assignments), and where the guy in question does discuss how to make gcc  
work nice with both Apple's application framework and the GPL clone of it.

Oh, and one intern working right now to improve gcc's errors-and-warnings  
code, because that's what the gcc list came up with as a task.

Sure, that's not many people in such a large company, but it's a vast  
difference from MS, and it's also a vast difference from the earlier Apple  
from the look-and-feel lawsuit age.

For a while, they also paid someone for working on Debian's packaging tool  
(dpkg) which they now use for Darwin; at the time, that guy was  
practically the dpkg lead developer.

And don't forget MkLinux.

Apple is not another Red Hat, but they're not a Black Hat either.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: The latest Microsoft FUD. This time from BillG, himself.

[Kai Henningsen]

[EMAIL PROTECTED] (Rob Landley)  wrote on 22.06.01 in 
[EMAIL PROTECTED]:

 On Thursday 21 June 2001 18:49, Alan Cox wrote:

   Except that Apple keeps the old code open. Probably because
   they'll gain nothing from it, and at best, they can appeal to
   the techies.
 
  A company that seems to write 'you shall not work on open source projects
  in your spare time' into its employment contracts is not what I would call
  friendly or want to work for. Im sure its only a small step to 'employees
  shall not snowboard' 'employees shall not go skiing' - all of course
  argued for the same reason as being essential to the company interest

 This IS the company that had the I work 90 hours all the time club with
 t-shirts and everything back under Jobs in the early 80's.  And far more
 recently, where at least one employee got in trouble for thinking
 different' with a parody site involving famous serial killers.

 The Proprietary frosting model is fine for leaf-node projects like games.
 But if the new layer is infrastructure other people are expected to build on
 top of, then what you're really saying is I want slaves.

Hmm. This *is* the company that has at least one guy full-time working on  
merging their changes back into gcc (with the right Copyright  
assignments), and where the guy in question does discuss how to make gcc  
work nice with both Apple's application framework and the GPL clone of it.

Oh, and one intern working right now to improve gcc's errors-and-warnings  
code, because that's what the gcc list came up with as a task.

Sure, that's not many people in such a large company, but it's a vast  
difference from MS, and it's also a vast difference from the earlier Apple  
from the look-and-feel lawsuit age.

For a while, they also paid someone for working on Debian's packaging tool  
(dpkg) which they now use for Darwin; at the time, that guy was  
practically the dpkg lead developer.

And don't forget MkLinux.

Apple is not another Red Hat, but they're not a Black Hat either.

MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: temperature standard - global config option?

[Kai Henningsen]

[EMAIL PROTECTED] (Lauri Tischler)  wrote on 21.06.01 in 
<[EMAIL PROTECTED]>:

> Richard J Moore wrote:
> >
> > > 59.42886726469 ±2°C is obviously ludicrous, even if that's
> > > what my calculator gives me.  I should instead write 59 ±2°C, since
> >
> > So, if I follow you argument then shouldn't you be writing 58 ±2°C or
> > should it be 60 ±2°C ?
>
> What it means is that whatever dingus measured the temperature, reported
> the temperature as 59C.

Well, maybe. And maybe it reported the temperature as "76 units", where a  
unit is approximately 0.69°C, and zero units are approximately 6.99°C, and  
we happen to know the accuracy is 3 units.

(That makes out to 59.43 ±2.07°C, or 57.36 to 61.50°C, whereas 59 ±2°C  
works out to 57.00 to 61.00°C - they do overlap, but they're not the same.  
Now you might not care - but then again, you might care.)

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: temperature standard - global config option?

[Kai Henningsen]

[EMAIL PROTECTED] (Chris Boot)  wrote on 08.06.01 in <[EMAIL PROTECTED]>:

> > Only the truly stupid would assume accuracy from decimal places.
>
> Well then, tell all the teachers in this world that they're stupid, and tell
> everyone who learnt from them as well.

*All*?

> I'm in high school (gd. 11, junior)
> and my physics teacher is always screaming at us for putting too many
> decimal places or having them inconsistent.

Ok, *yours*.

But yours is not all. I certainly don't remember ever seeing that attitude  
in school.

And yes, this behaviour *is* stupid. Someone who thinks like that should  
never be allowed to become a science teacher.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: temperature standard - global config option?

[Kai Henningsen]

[EMAIL PROTECTED] (Chris Boot)  wrote on 08.06.01 in [EMAIL PROTECTED]:

  Only the truly stupid would assume accuracy from decimal places.

 Well then, tell all the teachers in this world that they're stupid, and tell
 everyone who learnt from them as well.

*All*?

 I'm in high school (gd. 11, junior)
 and my physics teacher is always screaming at us for putting too many
 decimal places or having them inconsistent.

Ok, *yours*.

But yours is not all. I certainly don't remember ever seeing that attitude  
in school.

And yes, this behaviour *is* stupid. Someone who thinks like that should  
never be allowed to become a science teacher.

MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: temperature standard - global config option?

[Kai Henningsen]

[EMAIL PROTECTED] (Lauri Tischler)  wrote on 21.06.01 in 
[EMAIL PROTECTED]:

 Richard J Moore wrote:
 
   59.42886726469 ±2°C is obviously ludicrous, even if that's
   what my calculator gives me.  I should instead write 59 ±2°C, since
 
  So, if I follow you argument then shouldn't you be writing 58 ±2°C or
  should it be 60 ±2°C ?

 What it means is that whatever dingus measured the temperature, reported
 the temperature as 59C.

Well, maybe. And maybe it reported the temperature as 76 units, where a  
unit is approximately 0.69°C, and zero units are approximately 6.99°C, and  
we happen to know the accuracy is 3 units.

(That makes out to 59.43 ±2.07°C, or 57.36 to 61.50°C, whereas 59 ±2°C  
works out to 57.00 to 61.00°C - they do overlap, but they're not the same.  
Now you might not care - but then again, you might care.)

MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Alan Cox quote?

[Kai Henningsen]

[EMAIL PROTECTED] (Larry McVoy)  wrote on 19.06.01 in 
<[EMAIL PROTECTED]>:

> Another one that I can't believe I forgot is from Rob Pike:
>
> "If you think you need threads then your processes are too fat"
>
> And one from me:
>
> ``Think of it this way: threads are like salt, not like pasta. You
> like salt, I like salt, we all like salt. But we eat more pasta.''
>
> Threads are a really bad idea.  All you need are processes and either the
> ability to not fork the VM (Linux' clone, Plan 9's rfork) or just good
> old mmap(2).  If you allow threads then all you are saying is that your
> process model is so pathetic you had to invent another, supposedly lighter
> weight, object to do the same thing.

The funny thing here, Larry, is that to most people (who aren't OS gurus),  
Linux' clone or Plan 9's rfork *are* threads.

I certainly agree that you don't necessarily need two different kernel- 
level kinds of things, but really, most of the time when people talk about  
threads, they don't care one whit how their libraries manage to produce  
threads, as long as those threads actually work.

Threads are a kind of abstraction.

And the argument that you don't need threads when you have state machines  
is exactly as valid as the one that says that you don't need loops when  
you have goto.

Oh, you also don't need subroutines when you have state machines and goto.  
Fancy that!

I've even been told you can do all these things with nothing more than a  
Turing machine ...

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Alan Cox quote?

[Kai Henningsen]

[EMAIL PROTECTED] (Larry McVoy)  wrote on 19.06.01 in 
[EMAIL PROTECTED]:

 Another one that I can't believe I forgot is from Rob Pike:

 If you think you need threads then your processes are too fat

 And one from me:

 ``Think of it this way: threads are like salt, not like pasta. You
 like salt, I like salt, we all like salt. But we eat more pasta.''

 Threads are a really bad idea.  All you need are processes and either the
 ability to not fork the VM (Linux' clone, Plan 9's rfork) or just good
 old mmap(2).  If you allow threads then all you are saying is that your
 process model is so pathetic you had to invent another, supposedly lighter
 weight, object to do the same thing.

The funny thing here, Larry, is that to most people (who aren't OS gurus),  
Linux' clone or Plan 9's rfork *are* threads.

I certainly agree that you don't necessarily need two different kernel- 
level kinds of things, but really, most of the time when people talk about  
threads, they don't care one whit how their libraries manage to produce  
threads, as long as those threads actually work.

Threads are a kind of abstraction.

And the argument that you don't need threads when you have state machines  
is exactly as valid as the one that says that you don't need loops when  
you have goto.

Oh, you also don't need subroutines when you have state machines and goto.  
Fancy that!

I've even been told you can do all these things with nothing more than a  
Turing machine ...

MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Break 2.4 VM in five easy steps

[Kai Henningsen]

[EMAIL PROTECTED] (Alexander Viro)  wrote on 06.06.01 in 
<[EMAIL PROTECTED]>:

> On Wed, 6 Jun 2001, Sean Hunter wrote:
>
> > This is completely bogus. I am not saying that I can't afford the swap.
> > What I am saying is that it is completely broken to require this amount
> > of swap given the boundaries of efficient use.
>
> Funny. I can count many ways in which 4.3BSD, SunOS{3,4} and post-4.4 BSD
> systems I've used were broken, but I've never thought that swap==2*RAM rule
> was one of them.

As a "will break without" rule, I'd consider a kernel with that property  
completely unsuitable for production use. I certainly don't remember  
thinking of that as more than a recommendation back when I used commercial  
Unices (SysVsomething).

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Break 2.4 VM in five easy steps

[Kai Henningsen]

[EMAIL PROTECTED] (Alexander Viro)  wrote on 06.06.01 in 
[EMAIL PROTECTED]:

 On Wed, 6 Jun 2001, Sean Hunter wrote:

  This is completely bogus. I am not saying that I can't afford the swap.
  What I am saying is that it is completely broken to require this amount
  of swap given the boundaries of efficient use.

 Funny. I can count many ways in which 4.3BSD, SunOS{3,4} and post-4.4 BSD
 systems I've used were broken, but I've never thought that swap==2*RAM rule
 was one of them.

As a will break without rule, I'd consider a kernel with that property  
completely unsuitable for production use. I certainly don't remember  
thinking of that as more than a recommendation back when I used commercial  
Unices (SysVsomething).

MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Kai Henningsen]

[EMAIL PROTECTED] (Linus Torvalds)  wrote on 20.05.01 in 
<[EMAIL PROTECTED]>:

> If we had nice infrastructure to make ioctl's more palatable, we could
> probably make do even with the current binary-number interfaces, simply
> because people would use the infrastructure without ever even _seeing_ how
> lacking the user-level accesses are.
>
> But that absolutely _requires_ that the driver writers should never see
> the silly "pass a random number and a random argument type" kind of
> interface with no structure or infrastructure in place.

Hmm.

So would it be worthwile to invent some infrastructure - possibly  
including macros, possibly even including a (very small) code generator, I  
don't really have any details clear at this point - that allows you to  
specify an interface in a sane way (for example, but not necessarily, as a  
C function definition, though that may be too hard to parse), and have the  
infrastructure generate

1. some code to call ioctl() with these arguments
2. some other code to pick apart the ioctl buffer and call the actual
   function with these arguments

preferrably so that (a) the code from 1 is suitable for use in libc or  
similar places, (b) the code from 2 is suitable for the kernel, (c) most  
(all would be better but may not be practical) existing ioctls could be  
described that way?

(If so, the first task would obviously be to analyze existing code in  
those places, and the actual structure of existing ioctls, to find out  
what sort of stuff needs to be supported, before trying to design the  
mechanism to support it.)

A variant possibility (that I suspect you'll like significantly less)  
would be a data structure to describe the ioctl that gets interpreted at  
runtime. I think I prefer specific code for that job. At least *some*  
ioctls are in hot spots, and interpreting is slow. And that hypothetical  
encapsulation certainly should not know the difference between fast and  
slow interrupts^Wioctls.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Kai Henningsen]

[EMAIL PROTECTED] (Linus Torvalds)  wrote on 20.05.01 in 
[EMAIL PROTECTED]:

 If we had nice infrastructure to make ioctl's more palatable, we could
 probably make do even with the current binary-number interfaces, simply
 because people would use the infrastructure without ever even _seeing_ how
 lacking the user-level accesses are.

 But that absolutely _requires_ that the driver writers should never see
 the silly pass a random number and a random argument type kind of
 interface with no structure or infrastructure in place.

Hmm.

So would it be worthwile to invent some infrastructure - possibly  
including macros, possibly even including a (very small) code generator, I  
don't really have any details clear at this point - that allows you to  
specify an interface in a sane way (for example, but not necessarily, as a  
C function definition, though that may be too hard to parse), and have the  
infrastructure generate

1. some code to call ioctl() with these arguments
2. some other code to pick apart the ioctl buffer and call the actual
   function with these arguments

preferrably so that (a) the code from 1 is suitable for use in libc or  
similar places, (b) the code from 2 is suitable for the kernel, (c) most  
(all would be better but may not be practical) existing ioctls could be  
described that way?

(If so, the first task would obviously be to analyze existing code in  
those places, and the actual structure of existing ioctls, to find out  
what sort of stuff needs to be supported, before trying to design the  
mechanism to support it.)

A variant possibility (that I suspect you'll like significantly less)  
would be a data structure to describe the ioctl that gets interpreted at  
runtime. I think I prefer specific code for that job. At least *some*  
ioctls are in hot spots, and interpreting is slow. And that hypothetical  
encapsulation certainly should not know the difference between fast and  
slow interrupts^Wioctls.

MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: no ioctls for serial ports? [was Re: LANANA: To Pending Device Num

[Kai Henningsen]

[EMAIL PROTECTED] (Pavel Machek)  wrote on 19.05.01 in 
<[EMAIL PROTECTED]>:

> I think that plan9 uses something different -- they have ttyS0 and
> ttyS0ctl. This would leave us with problem "how do I get handle to
> ttyS0ctl when I only have handle to ttyS0"?

I've seen this question several times in this thread. I haven't seen the  
obvious answer, though.

Have a new system call:

ctlfd = open_device_control_fd(fd);

If fd is something that doesn't have a control interface (say, it already  
is a control filehandle), this returns an appropriate error code.

This has another benefit, in that you can get control descriptors for  
stuff that doesn't currently have a filename (but does have ioctls), such  
as network sockets.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: no ioctls for serial ports? [was Re: LANANA: To Pending Device Num

[Kai Henningsen]

[EMAIL PROTECTED] (Pavel Machek)  wrote on 19.05.01 in 
[EMAIL PROTECTED]:

 I think that plan9 uses something different -- they have ttyS0 and
 ttyS0ctl. This would leave us with problem how do I get handle to
 ttyS0ctl when I only have handle to ttyS0?

I've seen this question several times in this thread. I haven't seen the  
obvious answer, though.

Have a new system call:

ctlfd = open_device_control_fd(fd);

If fd is something that doesn't have a control interface (say, it already  
is a control filehandle), this returns an appropriate error code.

This has another benefit, in that you can get control descriptors for  
stuff that doesn't currently have a filename (but does have ioctls), such  
as network sockets.

MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Kai Henningsen]

[EMAIL PROTECTED] (Jonathan Lundell)  wrote on 17.05.01 in 
<p05100301b72a335d4b61@[10.128.7.49]>:

> At 11:23 PM +0200 2001-05-17, Kai Henningsen wrote:
> >[EMAIL PROTECTED] (Jonathan Lundell)  wrote on 15.05.01 in
> ><p05100316b7272cdfd50c@[207.213.214.37]>:
> >
> >>  What about:
> >>
> >>  1 (network domain). I have two network interfaces that I connect to
> >>  two different network segments, eth0 & eth1; they're ifconfig'd to
> >>  the appropriate IP and MAC addresses. I really do need to know
> >>  physically which (physical) hole to plug my eth0 cable into.
> >
> >Sorry, the software doesn't know that. Never has, for that matter.
>
> Well, no, it doesn't. That's a problem.

Maybe, but it's not a problem you can solve from the kernel.

> Jeff Garzik's ethtool
> extension at least tells me the PCI bus/dev/fcn, though, and from
> that I can write a userland mapping function to the physical
> location.

I don't see how PCI bus/dev/fcn lets you do that.

> My point, though, is that finding the socket is a real-life
> problem on systems with multiple interfaces. I don't expect the
> kernel to know the physical locations, but the user has to be able to
> get from kernel/ifconfig names (eth#) to sockets, one way or another.

Local documentation is just about the only way to do it.

And one way that'd work fairly well with at least PC network cards is  
putting a sticker with the MAC address on them where you can see it while  
looking for the right place to put your plug.

Not the only way, either.

> Support for a uniform means of doing the mapping, even if it needs
> userland help, would be good.

It doesn't need userland *or* kernel help.

> >  > (Extension: same situation, but it's a firewall and I've got 12 ports
> >>  to connect.) (Extension #2: if I add a NIC to the system and reboot,
> >>  I'd really prefer that the NICs already in use didn't get renumbered.)
> >
> >Make your config script look at the hardware MAC addresses. Those don't
> >change.
>
> They're not necessarily unique, though.

So if you plug both into the same network segment, that segment is broken?  
That looks like very stupid design to me.

It's not as if getting enough unique MAC addresses was particularly  
expensive. These days, even el-cheapo PC network cards get that right.  
(And have for quite a number of years.)

> >  > 2 (disk domain). I have multiple spindles on multiple SCSI adapters.
> >>  I want to allocate them to more than one RAID0/1/5 set, with the
> >>  usual considerations of putting mirrors on different adapters,
> >>  spreading my RAID5 drives optimally, ditto stripes. I need (eg) SCSI
> >>  paths to config all this, and I further need real physical locations
> >>  to identify failed drives that need to be hot-replaced. The mirror
> >>  members will move around as drives are replaced and hot spares come
> >>  into play.
> >
> >Use partition UUIDs, or SCSI serial numbers, or whatever. This works
> >today.
>
> This pushes the problem back in time: I need to write the UUID, for

But not the SCSI serial number.

> example, at some point. And, with hot-swappable drives, I'm still
> interested in the physical location. I really know know that there's
> a good answer to this problem, especially with FC, but I need to tell
> an operator, "replace this particular physical drive". It doesn't do
> any good to tell the operator the UUID.

Well, if it's a small system, any enumeration plus id-page query will let  
you identify *a* name for the device. There's no need for that name to be  
stable. (The only stable names you need are for mount and friends, and  
those can easily use UUIDs.)

In a big system, where presumably you use lots of similar drives, those  
better have some sort of serial number (which you can, of course, get at  
the same way as above). In that case, part of the preparation of a hot  
swap drive would be to put the serial number on a sticker on the drive (or  
put some other id there and note the correspondence in some database).

And, of course, your software can note which UUID goes with which serial  
number.

If your drives have *no* serial number, you can try a software one ... or  
follow the old advice: don't do that, then. Don't use unidentifiable  
drives in many-similar-drive production systems.

> >  > Seems like more that merely informational.
> >
> >The *location*? Nope. Some unique id for the device, if available at all:
> >sure.
>
> What good does it do to tell an operator to connect a cable to a MAC
> address? Or to remove a drive having a particular UUID? If it's "mere
> information", it's *necessary* mere information.

See above for how that works. As in, actually works in practice. As in, I  
really shouldn't have to explain this.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Kai Henningsen]

[EMAIL PROTECTED] (Johannes Erdfelt)  wrote on 17.05.01 in 
<[EMAIL PROTECTED]>:

> On Thu, May 17, 2001, Kai Henningsen <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] (Johannes Erdfelt)  wrote on 15.05.01 in
> > <[EMAIL PROTECTED]>:
> >
> > > 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.
> >
> > Not at all. What is unreasonable is douing a "ls" on the directory in
> > question.
> >
> > Big deal; make it mode d--x--x--x. Problem solved.
> >
> > And I'm pretty certain stuff like that *has* been done - wasn't there a
> > ftp file system where you could "ls /mountpoint/ftp.kernel.org/pub/linux"?
>
> I think this is the difference between reasonable and unreasonable.

What's unreasonable about it?

> I'm sure it could be done, but should it?

Well, the author of the Midnight Commander seems to think it should.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Kai Henningsen]

[EMAIL PROTECTED] (Johannes Erdfelt)  wrote on 17.05.01 in 
[EMAIL PROTECTED]:

 On Thu, May 17, 2001, Kai Henningsen [EMAIL PROTECTED] wrote:
  [EMAIL PROTECTED] (Johannes Erdfelt)  wrote on 15.05.01 in
  [EMAIL PROTECTED]:
 
   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.
 
  Not at all. What is unreasonable is douing a ls on the directory in
  question.
 
  Big deal; make it mode d--x--x--x. Problem solved.
 
  And I'm pretty certain stuff like that *has* been done - wasn't there a
  ftp file system where you could ls /mountpoint/ftp.kernel.org/pub/linux?

 I think this is the difference between reasonable and unreasonable.

What's unreasonable about it?

 I'm sure it could be done, but should it?

Well, the author of the Midnight Commander seems to think it should.

MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Kai Henningsen]

[EMAIL PROTECTED] (Jonathan Lundell)  wrote on 17.05.01 in 
p05100301b72a335d4b61@[10.128.7.49]:

 At 11:23 PM +0200 2001-05-17, Kai Henningsen wrote:
 [EMAIL PROTECTED] (Jonathan Lundell)  wrote on 15.05.01 in
 p05100316b7272cdfd50c@[207.213.214.37]:
 
   What about:
 
   1 (network domain). I have two network interfaces that I connect to
   two different network segments, eth0  eth1; they're ifconfig'd to
   the appropriate IP and MAC addresses. I really do need to know
   physically which (physical) hole to plug my eth0 cable into.
 
 Sorry, the software doesn't know that. Never has, for that matter.

 Well, no, it doesn't. That's a problem.

Maybe, but it's not a problem you can solve from the kernel.

 Jeff Garzik's ethtool
 extension at least tells me the PCI bus/dev/fcn, though, and from
 that I can write a userland mapping function to the physical
 location.

I don't see how PCI bus/dev/fcn lets you do that.

 My point, though, is that finding the socket is a real-life
 problem on systems with multiple interfaces. I don't expect the
 kernel to know the physical locations, but the user has to be able to
 get from kernel/ifconfig names (eth#) to sockets, one way or another.

Local documentation is just about the only way to do it.

And one way that'd work fairly well with at least PC network cards is  
putting a sticker with the MAC address on them where you can see it while  
looking for the right place to put your plug.

Not the only way, either.

 Support for a uniform means of doing the mapping, even if it needs
 userland help, would be good.

It doesn't need userland *or* kernel help.

(Extension: same situation, but it's a firewall and I've got 12 ports
   to connect.) (Extension #2: if I add a NIC to the system and reboot,
   I'd really prefer that the NICs already in use didn't get renumbered.)
 
 Make your config script look at the hardware MAC addresses. Those don't
 change.

 They're not necessarily unique, though.

So if you plug both into the same network segment, that segment is broken?  
That looks like very stupid design to me.

It's not as if getting enough unique MAC addresses was particularly  
expensive. These days, even el-cheapo PC network cards get that right.  
(And have for quite a number of years.)

2 (disk domain). I have multiple spindles on multiple SCSI adapters.
   I want to allocate them to more than one RAID0/1/5 set, with the
   usual considerations of putting mirrors on different adapters,
   spreading my RAID5 drives optimally, ditto stripes. I need (eg) SCSI
   paths to config all this, and I further need real physical locations
   to identify failed drives that need to be hot-replaced. The mirror
   members will move around as drives are replaced and hot spares come
   into play.
 
 Use partition UUIDs, or SCSI serial numbers, or whatever. This works
 today.

 This pushes the problem back in time: I need to write the UUID, for

But not the SCSI serial number.

 example, at some point. And, with hot-swappable drives, I'm still
 interested in the physical location. I really know know that there's
 a good answer to this problem, especially with FC, but I need to tell
 an operator, replace this particular physical drive. It doesn't do
 any good to tell the operator the UUID.

Well, if it's a small system, any enumeration plus id-page query will let  
you identify *a* name for the device. There's no need for that name to be  
stable. (The only stable names you need are for mount and friends, and  
those can easily use UUIDs.)

In a big system, where presumably you use lots of similar drives, those  
better have some sort of serial number (which you can, of course, get at  
the same way as above). In that case, part of the preparation of a hot  
swap drive would be to put the serial number on a sticker on the drive (or  
put some other id there and note the correspondence in some database).

And, of course, your software can note which UUID goes with which serial  
number.

If your drives have *no* serial number, you can try a software one ... or  
follow the old advice: don't do that, then. Don't use unidentifiable  
drives in many-similar-drive production systems.

Seems like more that merely informational.
 
 The *location*? Nope. Some unique id for the device, if available at all:
 sure.

 What good does it do to tell an operator to connect a cable to a MAC
 address? Or to remove a drive having a particular UUID? If it's mere
 information, it's *necessary* mere information.

See above for how that works. As in, actually works in practice. As in, I  
really shouldn't have to explain this.

MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Kai Henningsen]

[EMAIL PROTECTED] (H. Peter Anvin)  wrote on 16.05.01 in 
<[EMAIL PROTECTED]>:

> At some point something talks to the device -- in this case, it's the
> SCSI layer.  Follow the interfaces in the kernel and it becomes obvious.

rc = sys_iskind(int filehandle, const char *driverkind)

rc = 0 or Esomething

Think of it as a generalization of isatty(). Maybe

#define isatty(f) sys_iskind(f, "tty")

:-;

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Kai Henningsen]

[EMAIL PROTECTED] (Richard Gooch)  wrote on 16.05.01 in 
<[EMAIL PROTECTED]>:

> H. Peter Anvin writes:
> > Richard Gooch wrote:
> > >
> > > H. Peter Anvin writes:
> > > > Richard Gooch wrote:
> > > > > Argh! What I wrote in text is what I meant to say. The code didn't
> > > > > match. No wonder people seemed to be missing the point. So the line
> > > > > of code I actually meant was:
> > > > > if (strcmp (buffer + len - 3, "/cd") != 0) {
> > > >
> > > > This is still a really bad idea.  You don't want to tie this kind of
> > > > things to the name.
> > >
> > > Why do you think it's a bad idea?
> >
> > Because you are now, once again, tying two things that are
> > completely and utterly unrelated: device classification and device
> > name.  It breaks every time someone comes out with a new device
> > which is "kind of like an old device, but not really," like
> > CD-writers (which was kind-of-like WORM, kind-of-like CD-ROM) and
> > DVD (kind-of-like CD)...
>
> But all devices which export a CD-ROM interface will do so. So the
> device node that is associated with the CD-ROM driver will export
> CD-ROM semantics, and the trailing name will be "/cd".

Uh, how do they have the filename end in more than one device type suffix  
at the same time?

That was the point, remember. You're trying to find out about a device on  
the end of your file handle, and that device *does* match more than one of  
these.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Kai Henningsen]

[EMAIL PROTECTED] (Jonathan Lundell)  wrote on 15.05.01 in 
:

> What about:
>
> 1 (network domain). I have two network interfaces that I connect to
> two different network segments, eth0 & eth1; they're ifconfig'd to
> the appropriate IP and MAC addresses. I really do need to know
> physically which (physical) hole to plug my eth0 cable into.

Sorry, the software doesn't know that. Never has, for that matter.

> (Extension: same situation, but it's a firewall and I've got 12 ports
> to connect.) (Extension #2: if I add a NIC to the system and reboot,
> I'd really prefer that the NICs already in use didn't get renumbered.)

Make your config script look at the hardware MAC addresses. Those don't  
change.

> 2 (disk domain). I have multiple spindles on multiple SCSI adapters.
> I want to allocate them to more than one RAID0/1/5 set, with the
> usual considerations of putting mirrors on different adapters,
> spreading my RAID5 drives optimally, ditto stripes. I need (eg) SCSI
> paths to config all this, and I further need real physical locations
> to identify failed drives that need to be hot-replaced. The mirror
> members will move around as drives are replaced and hot spares come
> into play.

Use partition UUIDs, or SCSI serial numbers, or whatever. This works  
today.

> Seems like more that merely informational.

The *location*? Nope. Some unique id for the device, if available at all:  
sure.

> (A side observation: PCI or SCSI bus/device/lun/etc paths are not
> physical locations; you also need external hardware-specific
> knowledge to be able to talk about real physical locations in a way
> that does the system operator any good.)

And those you typically do not have.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Kai Henningsen]

[EMAIL PROTECTED] (Linus Torvalds)  wrote on 15.05.01 in 
<[EMAIL PROTECTED]>:

> They might also be exactly the same channel, except with certain magic
> bits set. The example peter gave was fine: tty devices could very usefully
> be opened with something like
>
>   fd = open("/dev/tty00/nonblock,9600,n8", O_RDWR);
>
> where we actually open up exactly the same channel as if we opened up
> /dev/cua00, we just set the speed etc at the same time. Which makes things
> a hell of a lot more readable, AND they are again easily done from
> scripts. The above is exactly the kind of thing that UNIX has not done
> well, and some others have done better (let's face it, even _DOS_ did it
> better, for chrissake! Those callout devices and those ioctl's are a pain
> in the ass, for no really good reason).

Umm ... where to begin.

1. No, DOS didn't do it better - DOS devices were mostly a bad copy of  
Xenix devices.

2. DOS definitely didn't do it better for serial ports. Serial ports are  
the single most broken devices that DOS supports by default, so much so  
that literally *no* serious program that needed the serial ports used the  
built-in driver. Only toy programs did that. Because those drivers weren't  
anything but toys themselves.

I know this the hard way. I used serial ports under DOS for something like  
ten years.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Kai Henningsen]

[EMAIL PROTECTED] (Johannes Erdfelt)  wrote on 15.05.01 in 
<[EMAIL PROTECTED]>:

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

Not at all. What is unreasonable is douing a "ls" on the directory in  
question.

Big deal; make it mode d--x--x--x. Problem solved.

And I'm pretty certain stuff like that *has* been done - wasn't there a  
ftp file system where you could "ls /mountpoint/ftp.kernel.org/pub/linux"?

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Kai Henningsen]

[EMAIL PROTECTED] (Johannes Erdfelt)  wrote on 15.05.01 in 
[EMAIL PROTECTED]:

 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.

Not at all. What is unreasonable is douing a ls on the directory in  
question.

Big deal; make it mode d--x--x--x. Problem solved.

And I'm pretty certain stuff like that *has* been done - wasn't there a  
ftp file system where you could ls /mountpoint/ftp.kernel.org/pub/linux?

MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Kai Henningsen]

[EMAIL PROTECTED] (Linus Torvalds)  wrote on 15.05.01 in 
[EMAIL PROTECTED]:

 They might also be exactly the same channel, except with certain magic
 bits set. The example peter gave was fine: tty devices could very usefully
 be opened with something like

   fd = open(/dev/tty00/nonblock,9600,n8, O_RDWR);

 where we actually open up exactly the same channel as if we opened up
 /dev/cua00, we just set the speed etc at the same time. Which makes things
 a hell of a lot more readable, AND they are again easily done from
 scripts. The above is exactly the kind of thing that UNIX has not done
 well, and some others have done better (let's face it, even _DOS_ did it
 better, for chrissake! Those callout devices and those ioctl's are a pain
 in the ass, for no really good reason).

Umm ... where to begin.

1. No, DOS didn't do it better - DOS devices were mostly a bad copy of  
Xenix devices.

2. DOS definitely didn't do it better for serial ports. Serial ports are  
the single most broken devices that DOS supports by default, so much so  
that literally *no* serious program that needed the serial ports used the  
built-in driver. Only toy programs did that. Because those drivers weren't  
anything but toys themselves.

I know this the hard way. I used serial ports under DOS for something like  
ten years.

MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Kai Henningsen]

[EMAIL PROTECTED] (Jonathan Lundell)  wrote on 15.05.01 in 
p05100316b7272cdfd50c@[207.213.214.37]:

 What about:

 1 (network domain). I have two network interfaces that I connect to
 two different network segments, eth0  eth1; they're ifconfig'd to
 the appropriate IP and MAC addresses. I really do need to know
 physically which (physical) hole to plug my eth0 cable into.

Sorry, the software doesn't know that. Never has, for that matter.

 (Extension: same situation, but it's a firewall and I've got 12 ports
 to connect.) (Extension #2: if I add a NIC to the system and reboot,
 I'd really prefer that the NICs already in use didn't get renumbered.)

Make your config script look at the hardware MAC addresses. Those don't  
change.

 2 (disk domain). I have multiple spindles on multiple SCSI adapters.
 I want to allocate them to more than one RAID0/1/5 set, with the
 usual considerations of putting mirrors on different adapters,
 spreading my RAID5 drives optimally, ditto stripes. I need (eg) SCSI
 paths to config all this, and I further need real physical locations
 to identify failed drives that need to be hot-replaced. The mirror
 members will move around as drives are replaced and hot spares come
 into play.

Use partition UUIDs, or SCSI serial numbers, or whatever. This works  
today.

 Seems like more that merely informational.

The *location*? Nope. Some unique id for the device, if available at all:  
sure.

 (A side observation: PCI or SCSI bus/device/lun/etc paths are not
 physical locations; you also need external hardware-specific
 knowledge to be able to talk about real physical locations in a way
 that does the system operator any good.)

And those you typically do not have.

MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Kai Henningsen]

[EMAIL PROTECTED] (H. Peter Anvin)  wrote on 16.05.01 in 
[EMAIL PROTECTED]:

 At some point something talks to the device -- in this case, it's the
 SCSI layer.  Follow the interfaces in the kernel and it becomes obvious.

rc = sys_iskind(int filehandle, const char *driverkind)

rc = 0 or Esomething

Think of it as a generalization of isatty(). Maybe

#define isatty(f) sys_iskind(f, tty)

:-;

MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Kai Henningsen]

[EMAIL PROTECTED] (Richard Gooch)  wrote on 16.05.01 in 
[EMAIL PROTECTED]:

 H. Peter Anvin writes:
  Richard Gooch wrote:
  
   H. Peter Anvin writes:
Richard Gooch wrote:
 Argh! What I wrote in text is what I meant to say. The code didn't
 match. No wonder people seemed to be missing the point. So the line
 of code I actually meant was:
 if (strcmp (buffer + len - 3, /cd) != 0) {
   
This is still a really bad idea.  You don't want to tie this kind of
things to the name.
  
   Why do you think it's a bad idea?
 
  Because you are now, once again, tying two things that are
  completely and utterly unrelated: device classification and device
  name.  It breaks every time someone comes out with a new device
  which is kind of like an old device, but not really, like
  CD-writers (which was kind-of-like WORM, kind-of-like CD-ROM) and
  DVD (kind-of-like CD)...

 But all devices which export a CD-ROM interface will do so. So the
 device node that is associated with the CD-ROM driver will export
 CD-ROM semantics, and the trailing name will be /cd.

Uh, how do they have the filename end in more than one device type suffix  
at the same time?

That was the point, remember. You're trying to find out about a device on  
the end of your file handle, and that device *does* match more than one of  
these.

MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Kai Henningsen]

[EMAIL PROTECTED] (James Simmons)  wrote on 15.05.01 in 
<[EMAIL PROTECTED]>:

> > > 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 USB cradle to PC.

I don't know about USB, but I do know about PPP.

The point is, Ethernet is *different* from PPP. The frame formats are  
different, even the protocols (aside from IP) are different.

It's similar to the difference between serial and parallel ports. Sure,  
for some things, they're the same - but for others, they really aren't,  
and that's why it makes sense to call the one ttyS0 and the other lp0.

Similar for eth0 vs. ppp0.

Yes, both are network interfaces. But no, you don't do ARP on ppp0, for  
example (you do LCP instead, and it does different stuff, too).

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Kai Henningsen]

[EMAIL PROTECTED] (H. Peter Anvin)  wrote on 15.05.01 in 
<[EMAIL PROTECTED]>:

> Personally, I would also like to see network devices manifest in the
> filesystem namespace like everything else.

Yes.

Can we have a meta-rule?

*Every* by-name kernel interface should have a filesystem variant.

That is, if there's a kernel interface where you give the kernel a string  
to identify an in-kernel object, there should be some place in the file  
system (after mounting any prerequisites) that will respond to a path  
ending in that name.

That doesn't necessarily mean the parent will be a readable directory -  
that would, of course, be preferrable, but if enumerating all objects is a  
problem, then dropping this requirement is much preferrable to not having  
a pathname.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Kai Henningsen]

[EMAIL PROTECTED] (Daniel Phillips)  wrote on 16.05.01 in 
<01051602593001.00406@starship>:

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

Sorry, but that turns out not to be the case.

There are some rules for devices called COMx (x=1..4, ports much more than  
interrupts[1]), but I haven't ever seen a box that had a "ttySx" label  
from the manufacturer. And you can easily renumber those; the BIOS uses a  
4-entry lookup table for the ports.

[1] COM1=3F8, COM2=2F8, COM3=3E8, COM2=2E8

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Kai Henningsen]

[EMAIL PROTECTED] (Daniel Phillips)  wrote on 16.05.01 in 
01051602593001.00406@starship:

 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.

Sorry, but that turns out not to be the case.

There are some rules for devices called COMx (x=1..4, ports much more than  
interrupts[1]), but I haven't ever seen a box that had a ttySx label  
from the manufacturer. And you can easily renumber those; the BIOS uses a  
4-entry lookup table for the ports.

[1] COM1=3F8, COM2=2F8, COM3=3E8, COM2=2E8

MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Kai Henningsen]

[EMAIL PROTECTED] (James Simmons)  wrote on 15.05.01 in 
[EMAIL PROTECTED]:

   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 USB cradle to PC.

I don't know about USB, but I do know about PPP.

The point is, Ethernet is *different* from PPP. The frame formats are  
different, even the protocols (aside from IP) are different.

It's similar to the difference between serial and parallel ports. Sure,  
for some things, they're the same - but for others, they really aren't,  
and that's why it makes sense to call the one ttyS0 and the other lp0.

Similar for eth0 vs. ppp0.

Yes, both are network interfaces. But no, you don't do ARP on ppp0, for  
example (you do LCP instead, and it does different stuff, too).

MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Kai Henningsen]

[EMAIL PROTECTED] (H. Peter Anvin)  wrote on 15.05.01 in 
[EMAIL PROTECTED]:

 Personally, I would also like to see network devices manifest in the
 filesystem namespace like everything else.

Yes.

Can we have a meta-rule?

*Every* by-name kernel interface should have a filesystem variant.

That is, if there's a kernel interface where you give the kernel a string  
to identify an in-kernel object, there should be some place in the file  
system (after mounting any prerequisites) that will respond to a path  
ending in that name.

That doesn't necessarily mean the parent will be a readable directory -  
that would, of course, be preferrable, but if enumerating all objects is a  
problem, then dropping this requirement is much preferrable to not having  
a pathname.

MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Getting FS access events

[Kai Henningsen]

[EMAIL PROTECTED] (Alexander Viro)  wrote on 15.05.01 in 
<[EMAIL PROTECTED]>:

> ... and Multics had all access to files through equivalent of mmap()
> in 60s. "Segments" in ls(1) got that name for a good reason.

Where's something called "segments" connected with ls(1)? I can't seem to  
find the reference.


MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Kai Henningsen]

[EMAIL PROTECTED] (Alan Cox)  wrote on 15.05.01 in 
<[EMAIL PROTECTED]>:

> > > 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 modules to
> load' question..

The same way the old root device does: not. Why should it? It doesn't tell  
you what to eat for lunch either.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Kai Henningsen]

[EMAIL PROTECTED] (Linus Torvalds)  wrote on 15.05.01 in 
<[EMAIL PROTECTED]>:

> just incredibly stupid today. There's a script for doing exactly this for
> SCSI. I forget what it's called, because I obviously think the thing is
> stupid, but giving people the power to do even silly things is what Linux
> is all about.

Are you maybe talking about scsidev? It can produce names like /dev/scsi/ 
sdh24-e000c0i12l0p1 (ugh). It can *also* create names like
/dev/scsi/QAt-p3 for "that's the third partition on the Quantum Atlas, I  
shouldn't put important stuff there because Quantums like to break". (The  
QAt part comes from a config file.)

The latter I've used for quite a while (until I found mount-by-UUID). The  
former is unspeakably ugly.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Kai Henningsen]

[EMAIL PROTECTED] (Alan Cox)  wrote on 15.05.01 in 
[EMAIL PROTECTED]:

   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 modules to
 load' question..

The same way the old root device does: not. Why should it? It doesn't tell  
you what to eat for lunch either.

MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: LANANA: To Pending Device Number Registrants

[Kai Henningsen]

[EMAIL PROTECTED] (Linus Torvalds)  wrote on 15.05.01 in 
[EMAIL PROTECTED]:

 just incredibly stupid today. There's a script for doing exactly this for
 SCSI. I forget what it's called, because I obviously think the thing is
 stupid, but giving people the power to do even silly things is what Linux
 is all about.

Are you maybe talking about scsidev? It can produce names like /dev/scsi/ 
sdh24-e000c0i12l0p1 (ugh). It can *also* create names like
/dev/scsi/QAt-p3 for that's the third partition on the Quantum Atlas, I  
shouldn't put important stuff there because Quantums like to break. (The  
QAt part comes from a config file.)

The latter I've used for quite a while (until I found mount-by-UUID). The  
former is unspeakably ugly.

MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Getting FS access events

[Kai Henningsen]

[EMAIL PROTECTED] (Alexander Viro)  wrote on 15.05.01 in 
[EMAIL PROTECTED]:

 ... and Multics had all access to files through equivalent of mmap()
 in 60s. Segments in ls(1) got that name for a good reason.

Where's something called segments connected with ls(1)? I can't seem to  
find the reference.


MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Not a typewriter

[Kai Henningsen]

[EMAIL PROTECTED]  wrote on 11.05.01 in <[EMAIL PROTECTED]>:

> I think man is the best help system ever devised.  (The GNU Info system,
> however, is the spawn of Satan. :-)

Both have good and bad parts. HTML and PDF are yet other such candidates.

Something better is needed, but no two people seem to agree on what  
exactly it should be.

What I want: search support at least as good as Info (which is not very,  
but better than the other two); structure like man; support for both short  
refcard style and long reference book style treatments; one standard  
format that can be supported on console, X, or via a Web interface ... oh,  
and standard key bindings at least don't force people to play at Emacs.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: page_launder() bug

[Kai Henningsen]

[EMAIL PROTECTED] (Linus Torvalds)  wrote on 13.05.01 in 
<[EMAIL PROTECTED]>:

> And that's why I'd rather have generic support for _any_ page mapping that
> wants to drop pages early than have specific logic for swapping.
> Historically, we've always had very good results from trying to avoid
> having special cases and instead trying to find what the common rules
> might be.

Just a thought: isn't a dead swap page a rather similar condition to a  
page in a file without any links, open file descriptors, or open mmaps? In  
both cases, writeback really makes no sense.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: IPv6: the same address can be added multiple times

[Kai Henningsen]

[EMAIL PROTECTED] (David S. Miller)  wrote on 13.05.01 in 
<[EMAIL PROTECTED]>:

> Pekka Savola writes:
>  > But it still looks dirty.  Also, it's easier to add it many times by
>  > mistake; IPv4 addresses do not allow this.  And as you have to remove
>  > them N times too, this may create even more confusion.
>
> There is this growing (think growing as in "fungus") set of thinking
> that just because something can be misused, this is an argument
> against it even existing.

But that does not seem to be the argument here. Rather, it is "I can  
certainly see where this can cause harm, but I cannot see where it is  
useful for anything at all, so why do we have it?".

> I think this is wrong.  I'm seeing it a lot, especially on this list,
> and it's becomming a real concern at least to me.
>
> Most of the time the argument goes like:
>
> 1: "Well, we allow this because you can do usefull things X Y and
> Z as a result."

What is X, Y and Z in this particular case? Nobody seems to have said  
that.

Incidentally, this thread is *very* similar to the "mount the exact same  
FS several times on the exact same mountpoint" thing. I'd expect to get a  
similar resolution (i.e., *don't* allow that).

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: page_launder() bug

[Kai Henningsen]

[EMAIL PROTECTED] (Linus Torvalds)  wrote on 13.05.01 in 
[EMAIL PROTECTED]:

 And that's why I'd rather have generic support for _any_ page mapping that
 wants to drop pages early than have specific logic for swapping.
 Historically, we've always had very good results from trying to avoid
 having special cases and instead trying to find what the common rules
 might be.

Just a thought: isn't a dead swap page a rather similar condition to a  
page in a file without any links, open file descriptors, or open mmaps? In  
both cases, writeback really makes no sense.

MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: IPv6: the same address can be added multiple times

[Kai Henningsen]

[EMAIL PROTECTED] (David S. Miller)  wrote on 13.05.01 in 
[EMAIL PROTECTED]:

 Pekka Savola writes:
   But it still looks dirty.  Also, it's easier to add it many times by
   mistake; IPv4 addresses do not allow this.  And as you have to remove
   them N times too, this may create even more confusion.

 There is this growing (think growing as in fungus) set of thinking
 that just because something can be misused, this is an argument
 against it even existing.

But that does not seem to be the argument here. Rather, it is I can  
certainly see where this can cause harm, but I cannot see where it is  
useful for anything at all, so why do we have it?.

 I think this is wrong.  I'm seeing it a lot, especially on this list,
 and it's becomming a real concern at least to me.

 Most of the time the argument goes like:

 1: Well, we allow this because you can do usefull things X Y and
 Z as a result.

What is X, Y and Z in this particular case? Nobody seems to have said  
that.

Incidentally, this thread is *very* similar to the mount the exact same  
FS several times on the exact same mountpoint thing. I'd expect to get a  
similar resolution (i.e., *don't* allow that).

MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Not a typewriter

[Kai Henningsen]

[EMAIL PROTECTED]  wrote on 11.05.01 in [EMAIL PROTECTED]:

 I think man is the best help system ever devised.  (The GNU Info system,
 however, is the spawn of Satan. :-)

Both have good and bad parts. HTML and PDF are yet other such candidates.

Something better is needed, but no two people seem to agree on what  
exactly it should be.

What I want: search support at least as good as Info (which is not very,  
but better than the other two); structure like man; support for both short  
refcard style and long reference book style treatments; one standard  
format that can be supported on console, X, or via a Web interface ... oh,  
and standard key bindings at least don't force people to play at Emacs.

MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Nasty Requirements for non-GPL Linux Kernel Modules?

[Kai Henningsen]

[EMAIL PROTECTED] (Mike Galbraith)  wrote on 13.05.01 in 
<[EMAIL PROTECTED]>:

> On 13 May 2001, Kai Henningsen wrote:
>
> > [EMAIL PROTECTED] (Alan Cox)  wrote on 09.05.01 in
> > <[EMAIL PROTECTED]>:
> >
> > > > you stand, it'll cost you around $15K and that, in my opinion, is
> > > > fine. If it isn't worth $15K to protect your code then it is worth so
> > > > little to you that there really is no good reason not to just GPL it
> > > > from the start.
> > >
> > > Smart advice.
> >
> > Problem is, the people making that decision are not always the people
> > wanting to distribute the work in question, in which case the argument
> > doesn't work.
>
> if (!cost_analysis) goto darwinism;

Thank you for completely missing the point.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Nasty Requirements for non-GPL Linux Kernel Modules?

[Kai Henningsen]

[EMAIL PROTECTED] (Alan Cox)  wrote on 09.05.01 in 
<[EMAIL PROTECTED]>:

> > you stand, it'll cost you around $15K and that, in my opinion, is fine.
> > If it isn't worth $15K to protect your code then it is worth so little to
> > you that there really is no good reason not to just GPL it from the start.
>
> Smart advice.

Problem is, the people making that decision are not always the people  
wanting to distribute the work in question, in which case the argument  
doesn't work.

I don't know more about this specific case than what was said in the  
thread, but it sounds like a case in point.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Nasty Requirements for non-GPL Linux Kernel Modules?

[Kai Henningsen]

[EMAIL PROTECTED] (Alan Cox)  wrote on 09.05.01 in 
[EMAIL PROTECTED]:

  you stand, it'll cost you around $15K and that, in my opinion, is fine.
  If it isn't worth $15K to protect your code then it is worth so little to
  you that there really is no good reason not to just GPL it from the start.

 Smart advice.

Problem is, the people making that decision are not always the people  
wanting to distribute the work in question, in which case the argument  
doesn't work.

I don't know more about this specific case than what was said in the  
thread, but it sounds like a case in point.

MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Nasty Requirements for non-GPL Linux Kernel Modules?

[Kai Henningsen]

[EMAIL PROTECTED] (Mike Galbraith)  wrote on 13.05.01 in 
[EMAIL PROTECTED]:

 On 13 May 2001, Kai Henningsen wrote:

  [EMAIL PROTECTED] (Alan Cox)  wrote on 09.05.01 in
  [EMAIL PROTECTED]:
 
you stand, it'll cost you around $15K and that, in my opinion, is
fine. If it isn't worth $15K to protect your code then it is worth so
little to you that there really is no good reason not to just GPL it
from the start.
  
   Smart advice.
 
  Problem is, the people making that decision are not always the people
  wanting to distribute the work in question, in which case the argument
  doesn't work.

 if (!cost_analysis) goto darwinism;

Thank you for completely missing the point.

MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] adding PCI bus information to SCSI layer

[Kai Henningsen]

[EMAIL PROTECTED] (Jonathan Lundell)  wrote on 11.05.01 in 
:

> At 1:32 PM -0300 2001-05-11, Ralf Baechle wrote:
> >On Thu, May 03, 2001 at 12:51:25AM -0700, Jonathan Lundell wrote:
> >>  Kai Henningsen wrote:
> >>  >What's a lot more important is that the mail standards say that this
> >>  >stuff should not be interpreted by the receivers as needing wrapping,
> >>  >so irregardless of good or bad design it's just plain illegal.
> >>  >
> >>  >If you want to support wrapping with plain text, investigate
> >>  >format=flowed.
> >>
> >>  Yes, I did that.
> >>
> >  > I'm curious, though: I haven't found the mail standards that forbid
> >>  receivers to wrap long lines. Certainly many mail clients do it.
> >>  What's the relevant RFC?
> >
> >RFC 2822, 2.1.1.
>
> Thanks. It's not quite a standard yet, but it's true, it does limit
> lines to 998 characters. Sort of a strange limit, but there you
> are

It's the unchanged old RFC 821 SMTP line length limit [4.5.3 SIZES, text  
line] (the consequences are just spelt out more clearly). And 821 is from  
1982, so this is certainly not new in any sense of the word.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] adding PCI bus information to SCSI layer

[Kai Henningsen]

[EMAIL PROTECTED] (Jonathan Lundell)  wrote on 11.05.01 in 
p0510030db7221c090810@[10.128.7.49]·2:

 At 1:32 PM -0300 2001-05-11, Ralf Baechle wrote:
 On Thu, May 03, 2001 at 12:51:25AM -0700, Jonathan Lundell wrote:
   Kai Henningsen wrote:
   What's a lot more important is that the mail standards say that this
   stuff should not be interpreted by the receivers as needing wrapping,
   so irregardless of good or bad design it's just plain illegal.
   
   If you want to support wrapping with plain text, investigate
   format=flowed.
 
   Yes, I did that.
 
I'm curious, though: I haven't found the mail standards that forbid
   receivers to wrap long lines. Certainly many mail clients do it.
   What's the relevant RFC?
 
 RFC 2822, 2.1.1.

 Thanks. It's not quite a standard yet, but it's true, it does limit
 lines to 998 characters. Sort of a strange limit, but there you
 are

It's the unchanged old RFC 821 SMTP line length limit [4.5.3 SIZES, text  
line] (the consequences are just spelt out more clearly). And 821 is from  
1982, so this is certainly not new in any sense of the word.

MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: page_launder() bug

[Kai Henningsen]

[EMAIL PROTECTED] (Horst von Brand)  wrote on 07.05.01 in 
<[EMAIL PROTECTED]>:

> "David S. Miller" <[EMAIL PROTECTED]> said:
> > Jonathan Morton writes:
> >  > >-page_count(page) == (1 + !!page->buffers));
> >  >
> >  > Two inversions in a row?
> >
> > It is the most straightforward way to make a '1' or '0'
> > integer from the NULL state of a pointer.
>
> IMVHO, it is clearer to write:
>
>   page_count(page) == 1 + (page->buffers != NULL)
>
> At least, the original poster wouldn't have wondered, and I wouldn't have
> had to think a bit to find out what it meant... If gcc generates worse code
> for this, it should be fixed.

Huh. IMO, that is significantly *less* readable. And incidentally I'd be  
less certain that it actually does what you want - it is rather easy to  
convince yourself that !! has to do the right thing.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: page_launder() bug

[Kai Henningsen]

[EMAIL PROTECTED] (Horst von Brand)  wrote on 07.05.01 in 
[EMAIL PROTECTED]:

 David S. Miller [EMAIL PROTECTED] said:
  Jonathan Morton writes:
-page_count(page) == (1 + !!page-buffers));
   
Two inversions in a row?
 
  It is the most straightforward way to make a '1' or '0'
  integer from the NULL state of a pointer.

 IMVHO, it is clearer to write:

   page_count(page) == 1 + (page-buffers != NULL)

 At least, the original poster wouldn't have wondered, and I wouldn't have
 had to think a bit to find out what it meant... If gcc generates worse code
 for this, it should be fixed.

Huh. IMO, that is significantly *less* readable. And incidentally I'd be  
less certain that it actually does what you want - it is rather easy to  
convince yourself that !! has to do the right thing.

MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] for iso8859-13

[Kai Henningsen]

[EMAIL PROTECTED] (H. Peter Anvin)  wrote on 06.05.01 in 
<9d4ut6$9b9$[EMAIL PROTECTED]>:

> Followup to:  <[EMAIL PROTECTED]>
> By author:Andrzej Krzysztofowicz <[EMAIL PROTECTED]>
> In newsgroup: linux.dev.kernel
> >
> > Hi,
> >The following patch removed unused and broken conversion table from
> > nls_iso8859-13.c.
> >
>
> Wouldn't it make a heck of a lot more sense if we had a preprocessor
> which could produce these kinds of tables from a more sensible input
> format (preferrably one which is already in use somewhere.)

For example from the tables on the Unicode webserver or from the IBM  
charset registry ...


MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] for iso8859-13

[Kai Henningsen]

[EMAIL PROTECTED] (H. Peter Anvin)  wrote on 06.05.01 in 
9d4ut6$9b9$[EMAIL PROTECTED]:

 Followup to:  [EMAIL PROTECTED]
 By author:Andrzej Krzysztofowicz [EMAIL PROTECTED]
 In newsgroup: linux.dev.kernel
 
  Hi,
 The following patch removed unused and broken conversion table from
  nls_iso8859-13.c.
 

 Wouldn't it make a heck of a lot more sense if we had a preprocessor
 which could produce these kinds of tables from a more sensible input
 format (preferrably one which is already in use somewhere.)

For example from the tables on the Unicode webserver or from the IBM  
charset registry ...


MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: need good linux *athlon* (tbird) motherboard..

[Kai Henningsen]

[EMAIL PROTECTED] (Jonadab the Unsightly One)  wrote on 04.05.01 in 
<[EMAIL PROTECTED]>:

> [EMAIL PROTECTED] (Dances With Crows) wrote:
>
> > Hmm.  For "Athlon", the thl consonant combination occurs in such a way
> > that the speaker can split the word into two syllables, "ath" and "lon",
>
> Yes, you can do that, but people typically don't.  Not sure why.

Strange. I wouldn't dream of doing it any other way. The "A-thlon" version  
seems extremely unlikely to me.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: need good linux *athlon* (tbird) motherboard..

[Kai Henningsen]

[EMAIL PROTECTED] (Jonadab the Unsightly One)  wrote on 04.05.01 in 
[EMAIL PROTECTED]:

 [EMAIL PROTECTED] (Dances With Crows) wrote:

  Hmm.  For Athlon, the thl consonant combination occurs in such a way
  that the speaker can split the word into two syllables, ath and lon,

 Yes, you can do that, but people typically don't.  Not sure why.

Strange. I wouldn't dream of doing it any other way. The A-thlon version  
seems extremely unlikely to me.

MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: X15 alpha release: as fast as TUX but in user space (fwd)

[Kai Henningsen]

[EMAIL PROTECTED] (Pavel Machek)  wrote on 30.04.01 in <[EMAIL PROTECTED]>:

> PS: Hmm, how do you do timewarp for just one userland appliation with
> this installed?

1. What on earth for?

2. How do you do it today, and why wouldn't that work?


MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] adding PCI bus information to SCSI layer

[Kai Henningsen]

[EMAIL PROTECTED] (Jonathan Lundell)  wrote on 26.04.01 in 
:

> At 10:31 PM -0600 2001-04-26, Richard Gooch wrote:
> >BTW: please fix your mailer to do linewrap at 72 characters. Your
> >lines are hundreds of characters long, and that's hard to read.
>
> Sorry for the inconvenience. There are a lot of reasons why I believe
> it's properly a display function to wrap long lines, and that an MUA
> has no business altering outgoing messages (one on-topic reason being
> that patches get screwed up by inserted newlines), but I grant that
> there are broken clients out there that can't or won't or don't wrap
> at display time.

What's a lot more important is that the mail standards say that this stuff  
should not be interpreted by the receivers as needing wrapping, so  
irregardless of good or bad design it's just plain illegal.

If you want to support wrapping with plain text, investigate  
format=flowed.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: X15 alpha release: as fast as TUX but in user space (fwd)

[Kai Henningsen]

[EMAIL PROTECTED] (Pavel Machek)  wrote on 30.04.01 in [EMAIL PROTECTED]:

 PS: Hmm, how do you do timewarp for just one userland appliation with
 this installed?

1. What on earth for?

2. How do you do it today, and why wouldn't that work?


MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] adding PCI bus information to SCSI layer

[Kai Henningsen]

[EMAIL PROTECTED] (Jonathan Lundell)  wrote on 26.04.01 in 
p05100303b70eadd613b0@[207.213.214.37]:

 At 10:31 PM -0600 2001-04-26, Richard Gooch wrote:
 BTW: please fix your mailer to do linewrap at 72 characters. Your
 lines are hundreds of characters long, and that's hard to read.

 Sorry for the inconvenience. There are a lot of reasons why I believe
 it's properly a display function to wrap long lines, and that an MUA
 has no business altering outgoing messages (one on-topic reason being
 that patches get screwed up by inserted newlines), but I grant that
 there are broken clients out there that can't or won't or don't wrap
 at display time.

What's a lot more important is that the mail standards say that this stuff  
should not be interpreted by the receivers as needing wrapping, so  
irregardless of good or bad design it's just plain illegal.

If you want to support wrapping with plain text, investigate  
format=flowed.

MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.3.1, aka "I stick my neck out a mile..."

[Kai Henningsen]

[EMAIL PROTECTED] (Alexander Viro)  wrote on 30.04.01 in 
<[EMAIL PROTECTED]>:

> On Mon, 30 Apr 2001, Eric S. Raymond wrote:
>
> > I don't think I've heard anyone invoke the 4-line rule since about
> > 1992, though.  I didn't start generating short random quotes into my sig
> > until about 1996, well after the "standard" was effectively dead.
>
>  We hang in different parts of USENET 
>
> Last time I've seen it invoked was probably a couple of weeks ago.

I think I see it at least once a week on average. And that's gone *up*  
from earlier; in my first Usenet days (pre-Deja), I saw much less of it.


MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.3.1, aka I stick my neck out a mile...

[Kai Henningsen]

[EMAIL PROTECTED] (Alexander Viro)  wrote on 30.04.01 in 
[EMAIL PROTECTED]:

 On Mon, 30 Apr 2001, Eric S. Raymond wrote:

  I don't think I've heard anyone invoke the 4-line rule since about
  1992, though.  I didn't start generating short random quotes into my sig
  until about 1996, well after the standard was effectively dead.

 wry We hang in different parts of USENET /wry

 Last time I've seen it invoked was probably a couple of weeks ago.

I think I see it at least once a week on average. And that's gone *up*  
from earlier; in my first Usenet days (pre-Deja), I saw much less of it.


MfG Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Should mount --bind not follow symlinks?

[Kai Henningsen]

[EMAIL PROTECTED] (Alexander Viro)  wrote on 12.03.01 in 
<[EMAIL PROTECTED]>:

> On Mon, 12 Mar 2001, Anthony Heading wrote:
>
> > Hi,
> > My automounted dirs have up till now been symlinks, where
> > e.g. /opt/perl defaults to automounting /export/opt/perl/LATEST
> > which is a symlink.
> >
> >This all worked OK until the 2.4(.2) automounter helpfully tries
> > to mount --bind /export/opt/perl/LATEST /opt/perl
>
> Don't mix symlinks with mounts/bindings. Too much PITA and yes, it had
> been deliberately prohibited. You _really_ don't want to handle the
> broken symlinks and all the realted fun - race-ridden at extreme and
> useless.

Race? Where? You resolve the symlink once and operate on the result. No  
need to remember anywhere that it ever was a symlink. If there *can* be a  
race, this sounds like a serious design bug.

This looks like it *seriously* breaks my current 2.2 setup: I have dirs  
with sensible names under /Partition, and symlinks to those dirs whose  
name is the UUID for mount to use. Nothing automount in here. (And of  
course all those links and directories are completely static and only root- 
modifiable anyway, this only changes when I repartition.)

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Should mount --bind not follow symlinks?

[Kai Henningsen]

[EMAIL PROTECTED] (Alexander Viro)  wrote on 12.03.01 in 
[EMAIL PROTECTED]:

 On Mon, 12 Mar 2001, Anthony Heading wrote:

  Hi,
  My automounted dirs have up till now been symlinks, where
  e.g. /opt/perl defaults to automounting /export/opt/perl/LATEST
  which is a symlink.
 
 This all worked OK until the 2.4(.2) automounter helpfully tries
  to mount --bind /export/opt/perl/LATEST /opt/perl

 Don't mix symlinks with mounts/bindings. Too much PITA and yes, it had
 been deliberately prohibited. You _really_ don't want to handle the
 broken symlinks and all the realted fun - race-ridden at extreme and
 useless.

Race? Where? You resolve the symlink once and operate on the result. No  
need to remember anywhere that it ever was a symlink. If there *can* be a  
race, this sounds like a serious design bug.

This looks like it *seriously* breaks my current 2.2 setup: I have dirs  
with sensible names under /Partition, and symlinks to those dirs whose  
name is the UUID for mount to use. Nothing automount in here. (And of  
course all those links and directories are completely static and only root- 
modifiable anyway, this only changes when I repartition.)

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [kbuild-devel] Re: CML1 cleanup patch

[Kai Henningsen]

Warning: No kernel related stuff inside.

[EMAIL PROTECTED] (Rik van Riel)  wrote on 26.03.01 in 
<[EMAIL PROTECTED]>:

> On Mon, 26 Mar 2001, John Cowan wrote:

> > In fact this has come up before: in Usenet software, which has to
> > differentiate between an article and a sub-newsgroup.  An article has
> > to have an all-numeric name, and It Would Have Been Nice if all
> > newsgroup names began with non-digits, but then there was
> > comp.bugs.4bsd.
>
> What's wrong with using the _file type_ for these things ?

Wrong problem description, really. The problem is not components starting  
with digits, the problem is all-numeric components as in alt.2600.

And the problem is that this hits a fast path in the classical news spool  
layout article create path. The code for this assumes that you have  
articles in the range X to Y, and you just got a new article, so you write  
a file called /var/spool/news/group/name/Y+1. You really do not want to  
cope with the possibility of a directory Y+1 existing in that place.

I think there are some other things that also get impacted on their fast  
path, but this is probably the most important.

And then, it's an ugly user interface: the classical spool layout does  
assume that you look at that scpool with Unix tools (like find and grep),  
not only via NNTP and the server.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [kbuild-devel] Re: CML1 cleanup patch

[Kai Henningsen]

Warning: No kernel related stuff inside.

[EMAIL PROTECTED] (Rik van Riel)  wrote on 26.03.01 in 
[EMAIL PROTECTED]:

 On Mon, 26 Mar 2001, John Cowan wrote:

  In fact this has come up before: in Usenet software, which has to
  differentiate between an article and a sub-newsgroup.  An article has
  to have an all-numeric name, and It Would Have Been Nice if all
  newsgroup names began with non-digits, but then there was
  comp.bugs.4bsd.

 What's wrong with using the _file type_ for these things ?

Wrong problem description, really. The problem is not components starting  
with digits, the problem is all-numeric components as in alt.2600.

And the problem is that this hits a fast path in the classical news spool  
layout article create path. The code for this assumes that you have  
articles in the range X to Y, and you just got a new article, so you write  
a file called /var/spool/news/group/name/Y+1. You really do not want to  
cope with the possibility of a directory Y+1 existing in that place.

I think there are some other things that also get impacted on their fast  
path, but this is probably the most important.

And then, it's an ugly user interface: the classical spool layout does  
assume that you look at that scpool with Unix tools (like find and grep),  
not only via NNTP and the server.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Multi-function PCI devices

[Kai Henningsen]

[EMAIL PROTECTED] (Tim Waugh)  wrote on 07.04.01 in <[EMAIL PROTECTED]>:

> On Sat, Apr 07, 2001 at 01:23:27PM -0400, Jeff Garzik wrote:
>
> > You asked in your last message to show you code, here is a short
> > example.  Note that I would love to rip out the SUPERIO code in parport
> > and make it a separate driver like this short, contrived example.  Much
> > more modular than the existing solution.
>
> (The superio code is on its way out anyway, for different reasons..)
>
> More modular?  Yes, it adds another module to support a card, so yes
> there are more modules.
>
> But with the multifunction_quirks approach, support is a question of
> adding two lines in a table.

So why not make Jeff's example use a multifunction board table to do it's  
job?

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Multi-function PCI devices

[Kai Henningsen]

[EMAIL PROTECTED] (Tim Waugh)  wrote on 07.04.01 in [EMAIL PROTECTED]:

 On Sat, Apr 07, 2001 at 01:23:27PM -0400, Jeff Garzik wrote:

  You asked in your last message to show you code, here is a short
  example.  Note that I would love to rip out the SUPERIO code in parport
  and make it a separate driver like this short, contrived example.  Much
  more modular than the existing solution.

 (The superio code is on its way out anyway, for different reasons..)

 More modular?  Yes, it adds another module to support a card, so yes
 there are more modules.

 But with the multifunction_quirks approach, support is a question of
 adding two lines in a table.

So why not make Jeff's example use a multifunction board table to do it's  
job?

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: bug database braindump from the kernel summit

[Kai Henningsen]

[EMAIL PROTECTED] (Ben Ford)  wrote on 01.04.01 in <[EMAIL PROTECTED]>:

> Why not have the /proc/config option but instead of being plain text,
> make it binary with a userspace app that can interpret it?
>
> It could have a signature as to kernel version + patches and the rest
> would be just bits.

> You'd have
> 2.4.3-pre3:110101 . . . . .

Another option would be to put a checksum of the config, and still keep  
the config separate - at least you could tell if you had the right config  
for the kernel.


MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: bug database braindump from the kernel summit

[Kai Henningsen]

[EMAIL PROTECTED] (Ben Ford)  wrote on 01.04.01 in [EMAIL PROTECTED]:

 Why not have the /proc/config option but instead of being plain text,
 make it binary with a userspace app that can interpret it?

 It could have a signature as to kernel version + patches and the rest
 would be just bits.

 You'd have
 2.4.3-pre3:110101 . . . . .

Another option would be to put a checksum of the config, and still keep  
the config separate - at least you could tell if you had the right config  
for the kernel.


MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: New directions for kernel development

[Kai Henningsen]

[EMAIL PROTECTED] (john slee)  wrote on 01.04.01 in 
<[EMAIL PROTECTED]>:

> On Sun, Apr 01, 2001 at 01:22:48AM -0800, Richard Gooch wrote:
> > Linus Torvalds writes:
> >
> > Ho, hum. No, he didn't. It's April Wankers^WFools again.
>
> we aussies are supposed to have a good sense of humour :P

Yeah, but this one was fairly lame.


MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] sane access to per-fs metadata (was Re: [PATCH] Documentatio

[Kai Henningsen]

[EMAIL PROTECTED] (Chip Salzenberg)  wrote on 01.04.01 in :

> Why not have a kernel thread and use standard RPC techniques like
> sockets?  Then you'd not have to invent anything unimportant like
> Yet Another IPC Technique.

You can, of course, transfer the exact same RPC messages over a file  
descriptor on your metadata fs. It doesn't *have* to be ASCII, especially  
not for purely internal-use interfaces.

And for ioctl() fans, you could transfer the exact same data via read()/ 
write() again. That's not significantly harder. Especially if you write a  
wrapper around the calls. If you want to be perverse, you can probably  
even transmit user space pointers.

But I suspect there are really only two generally useful interfaces:

1. A text based interface for generally-useful stuff you might want to  
manipulate from the shell, or random user programs. (From the shell _is_  
random user programs.)

2. A RPC based interface for tightly-coupled fs utilities. (I don't know  
off the top of my head what the kernel already has - ISTR networking has  
_something_.)

Don't forget a version marker of some kind. Sooner or later, you'll be  
glad you have it.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] sane access to per-fs metadata (was Re: [PATCH] Documentatio

[Kai Henningsen]

[EMAIL PROTECTED] (Chip Salzenberg)  wrote on 01.04.01 in E14jdkF-0007Ps-00@tytlal:

 Why not have a kernel thread and use standard RPC techniques like
 sockets?  Then you'd not have to invent anything unimportant like
 Yet Another IPC Technique.

You can, of course, transfer the exact same RPC messages over a file  
descriptor on your metadata fs. It doesn't *have* to be ASCII, especially  
not for purely internal-use interfaces.

And for ioctl() fans, you could transfer the exact same data via read()/ 
write() again. That's not significantly harder. Especially if you write a  
wrapper around the calls. If you want to be perverse, you can probably  
even transmit user space pointers.

But I suspect there are really only two generally useful interfaces:

1. A text based interface for generally-useful stuff you might want to  
manipulate from the shell, or random user programs. (From the shell _is_  
random user programs.)

2. A RPC based interface for tightly-coupled fs utilities. (I don't know  
off the top of my head what the kernel already has - ISTR networking has  
_something_.)

Don't forget a version marker of some kind. Sooner or later, you'll be  
glad you have it.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: New directions for kernel development

[Kai Henningsen]

[EMAIL PROTECTED] (john slee)  wrote on 01.04.01 in 
[EMAIL PROTECTED]:

 On Sun, Apr 01, 2001 at 01:22:48AM -0800, Richard Gooch wrote:
  Linus Torvalds writes:
 
  Ho, hum. No, he didn't. It's April Wankers^WFools again.

 we aussies are supposed to have a good sense of humour :P

Yeah, but this one was fairly lame.


MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Larger dev_t

[Kai Henningsen]

[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 without having to
> > > suddenly start knowing about /dev/disk0.
> >
> > 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
>
> Why do you worry about installers? New distro - new kernel - new
> installer
> that's they job to worry about it. They will change the installer anyway
> and this kind of change actually is going to simplyfy the code there, I
> think,
> a bit.
>
> Just kill the old device major suddenly and place it in the changelog
> of the new kernel that the user should mknod and add it to /dev/fstab
> before rebooting into the new kernel. Hey that's developement anyway :-)
> If the developer boots back into the old kernel just other mounts
>  in /dev/fstab will fail no problem for transition here in sight...

Make them finally use UUIDs and /proc/partitions. Except for the root fs,  
problem solved. (Well ok, someone needs to create the right device nodes.)

As for the root fs, even that part isn't hard with an initrd.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Larger dev_t

[Kai Henningsen]

[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 without having to
   suddenly start knowing about /dev/disk0.
 
  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

 Why do you worry about installers? New distro - new kernel - new
 installer
 that's they job to worry about it. They will change the installer anyway
 and this kind of change actually is going to simplyfy the code there, I
 think,
 a bit.

 Just kill the old device major suddenly and place it in the changelog
 of the new kernel that the user should mknod and add it to /dev/fstab
 before rebooting into the new kernel. Hey that's developement anyway :-)
 If the developer boots back into the old kernel just other mounts
  in /dev/fstab will fail no problem for transition here in sight...

Make them finally use UUIDs and /proc/partitions. Except for the root fs,  
problem solved. (Well ok, someone needs to create the right device nodes.)

As for the root fs, even that part isn't hard with an initrd.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Version 6.1.8 of the aic7xxx driver availalbe

[Kai Henningsen]

[EMAIL PROTECTED] (Linus Torvalds)  wrote on 23.03.01 in 
<[EMAIL PROTECTED]>:

> On Thu, 22 Mar 2001, Justin T. Gibbs wrote:
> >
> > aic7xxx_proc.c:
> > Use an unsigned long for total number of commands
> > sent to a device.  %q and %lld don't seem to work
> > under Linux or I'd have used a uint64_t.
>
> It's "%Ld".
>
> Think ANSI "long long double" -> "Lf".
>
> Thus "long long int" -> "Ld".
>
> I know it's at least been discussed for ANSI C9X, although I have no idea
> if it actually caught on.

It went the other way:

ISO/IEC 9899:1999 (E) +ISO/IEC:

7 The length modifiers and their meanings are:

hh Specifies that a following d, i, o, u, x,or X conversion specifier  
applies to a signed char or unsigned char argument (the argument will have  
been promoted according to the integer promotions, but its value shall be  
converted to signed char or unsigned char before printing); or that a  
following n conversion specifier applies to a pointer to a signed char  
argument.

h Specifies that a following d, i, o, u, x,orX conversion specifier  
applies to a short int or unsigned short int argument (the argument will  
have been promoted according to the integer promotions, but its value  
shall be converted to short int or unsigned short int before printing); or  
that a following n conversion specifier applies to a pointer to a short  
int argument.

l (ell) Specifies that a following d, i, o, u, x,orX conversion specifier  
applies to a long int or unsigned long int argument; that a following n  
conversion specifier applies to a pointer to a long int argument; that a  
following c conversion specifier applies to a wint_t argument; that a  
following s conversion specifier applies to a pointer to a wchar_t  
argument; or has no effect on a following a, A, e, E, f, F, g, or G  
conversion specifier.

ll (ell-ell) Specifies that a following d, i, o, u, x,orX conversion  
specifier applies to a long long int or unsigned long long int argument;  
or that a following n conversion specifier applies to a pointer to a long  
long int argument.

j Specifies that a following d, i, o, u, x,orX conversion specifier  
applies to an intmax_t or uintmax_t argument; or that a following n  
conversion specifier applies to a pointer to an intmax_t argument.

z Specifies that a following d, i, o, u, x,orX conversion specifier  
applies to a size_t or the corresponding signed integer type argument; or  
that a following n conversion specifier applies to a pointer to a signed  
integer type corresponding to size_t argument.

t Specifies that a following d, i, o, u, x,orX conversion specifier  
applies to a ptrdiff_t or the corresponding unsigned integer type  
argument; or that a following n conversion specifier applies to a pointer  
to a ptrdiff_t argument.

L Specifies that a following a, A, e, E, f, F, g,orG conversion specifier applies to a 
long double argument. If a length modifier appears with any conversion specifier other 
than as specified above, the behavior is undefined.




MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Version 6.1.8 of the aic7xxx driver availalbe

[Kai Henningsen]

[EMAIL PROTECTED] (Linus Torvalds)  wrote on 23.03.01 in 
[EMAIL PROTECTED]:

 On Thu, 22 Mar 2001, Justin T. Gibbs wrote:
 
  aic7xxx_proc.c:
  Use an unsigned long for total number of commands
  sent to a device.  %q and %lld don't seem to work
  under Linux or I'd have used a uint64_t.

 It's "%Ld".

 Think ANSI "long long double" - "Lf".

 Thus "long long int" - "Ld".

 I know it's at least been discussed for ANSI C9X, although I have no idea
 if it actually caught on.

It went the other way:

ISO/IEC 9899:1999 (E) +ISO/IEC:

7 The length modifiers and their meanings are:

hh Specifies that a following d, i, o, u, x,or X conversion specifier  
applies to a signed char or unsigned char argument (the argument will have  
been promoted according to the integer promotions, but its value shall be  
converted to signed char or unsigned char before printing); or that a  
following n conversion specifier applies to a pointer to a signed char  
argument.

h Specifies that a following d, i, o, u, x,orX conversion specifier  
applies to a short int or unsigned short int argument (the argument will  
have been promoted according to the integer promotions, but its value  
shall be converted to short int or unsigned short int before printing); or  
that a following n conversion specifier applies to a pointer to a short  
int argument.

l (ell) Specifies that a following d, i, o, u, x,orX conversion specifier  
applies to a long int or unsigned long int argument; that a following n  
conversion specifier applies to a pointer to a long int argument; that a  
following c conversion specifier applies to a wint_t argument; that a  
following s conversion specifier applies to a pointer to a wchar_t  
argument; or has no effect on a following a, A, e, E, f, F, g, or G  
conversion specifier.

ll (ell-ell) Specifies that a following d, i, o, u, x,orX conversion  
specifier applies to a long long int or unsigned long long int argument;  
or that a following n conversion specifier applies to a pointer to a long  
long int argument.

j Specifies that a following d, i, o, u, x,orX conversion specifier  
applies to an intmax_t or uintmax_t argument; or that a following n  
conversion specifier applies to a pointer to an intmax_t argument.

z Specifies that a following d, i, o, u, x,orX conversion specifier  
applies to a size_t or the corresponding signed integer type argument; or  
that a following n conversion specifier applies to a pointer to a signed  
integer type corresponding to size_t argument.

t Specifies that a following d, i, o, u, x,orX conversion specifier  
applies to a ptrdiff_t or the corresponding unsigned integer type  
argument; or that a following n conversion specifier applies to a pointer  
to a ptrdiff_t argument.

L Specifies that a following a, A, e, E, f, F, g,orG conversion specifier applies to a 
long double argument. If a length modifier appears with any conversion specifier other 
than as specified above, the behavior is undefined.




MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/