Re: Why Plan 9 C compilers don't have asm("")
On Wed, Jul 04, 2001 at 09:54:05PM -0400, Rick Hohensee wrote:
> >
> > On Tue, Jul 03, 2001 at 11:37:28PM -0400, Rick Hohensee wrote:
> > > That's with the GNU tools, without asm(), and without proper declaration
> > > of printf, as is my tendency. I don't actually return an int either, do I?
> > > LAAETTR.
> >
> > Under ISO C rules, this is illegal, since you must have a proper prototype in
> > scope when calling variable argument functions. In fact, I have worked on
> > several GCC ports, where the compiler uses a different calling sequence for
> > variable argument functions than it does for normal functions. For example, on
> > the Mips, if the first argument is floating point and the number of arguments
> > is not variable, it is passed in a FP register, instead of an integer
> > register. For variable argument functions, everything is passed in the integer
> > registers.
> >
>
> I didn't know that, but...
>
> You seem to be saying the use of assumptions about args passing is
> non-standard. I know. It's more standard than GNU extensions to C though,
> C_labels_in_asms in particular, and even in your examples it appears that
> the particular function abusing these tenets will know what it can expect
> from a particular compiler, since it knows what it's arguments are. It
> can't know what it can expect from any compiler. This perhaps is where
> #ifdef comes in, or similar. Well, it's not more standard than GNU, but
> the differences would be less detailed in the case of just dealing with
> various args passing schemes, and there may be some compiler-to-compiler
> overlap, where there won't be any with stuff like C_labels_in_asms.
Doing this is a losing game. How many different platforms does Linux currently
run on? Do you know exactly what the ABI is for each of the machines? What
happens when Linux is ported to a new machine? My point is:
extern int printf (const char *, ...);
printf ("%d %d\n", 1, 2);
and
extern int my_printf (const char *, int, int);
my_printf ("%d %d\n", 1, 2);
under some ABIs will pass arguments completely differently and as I said, I
have worked on various GCC ports that did this, so it is not a theoretical
possibility.
> It's illegal to not declare main() as int. I don't know of a unix that
> actually passes anything but a byte to the calling process. I got flamed
> mightily for this in comp.unix.programmer until people ran some checks on
> thier big Real Unix(TM) boxes of various types. Linux won't pass void
> either, you have to get a 0 at least. Compliance is subjective. It's
> easier when things make sense.
Yes, that is an artifact of the original UNIX implementation on the PDP-11 (16
bit ints, signal number is passed back in one byte, and the return value in
another byte).
--
Michael Meissner, Red Hat, Inc. (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: [EMAIL PROTECTED] phone: +1 978-486-9304
Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482
-
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: Why Plan 9 C compilers don't have asm()
On Wed, Jul 04, 2001 at 09:54:05PM -0400, Rick Hohensee wrote: On Tue, Jul 03, 2001 at 11:37:28PM -0400, Rick Hohensee wrote: That's with the GNU tools, without asm(), and without proper declaration of printf, as is my tendency. I don't actually return an int either, do I? LAAETTR. Under ISO C rules, this is illegal, since you must have a proper prototype in scope when calling variable argument functions. In fact, I have worked on several GCC ports, where the compiler uses a different calling sequence for variable argument functions than it does for normal functions. For example, on the Mips, if the first argument is floating point and the number of arguments is not variable, it is passed in a FP register, instead of an integer register. For variable argument functions, everything is passed in the integer registers. I didn't know that, but... You seem to be saying the use of assumptions about args passing is non-standard. I know. It's more standard than GNU extensions to C though, C_labels_in_asms in particular, and even in your examples it appears that the particular function abusing these tenets will know what it can expect from a particular compiler, since it knows what it's arguments are. It can't know what it can expect from any compiler. This perhaps is where #ifdef comes in, or similar. Well, it's not more standard than GNU, but the differences would be less detailed in the case of just dealing with various args passing schemes, and there may be some compiler-to-compiler overlap, where there won't be any with stuff like C_labels_in_asms. Doing this is a losing game. How many different platforms does Linux currently run on? Do you know exactly what the ABI is for each of the machines? What happens when Linux is ported to a new machine? My point is: extern int printf (const char *, ...); printf (%d %d\n, 1, 2); and extern int my_printf (const char *, int, int); my_printf (%d %d\n, 1, 2); under some ABIs will pass arguments completely differently and as I said, I have worked on various GCC ports that did this, so it is not a theoretical possibility. It's illegal to not declare main() as int. I don't know of a unix that actually passes anything but a byte to the calling process. I got flamed mightily for this in comp.unix.programmer until people ran some checks on thier big Real Unix(TM) boxes of various types. Linux won't pass void either, you have to get a 0 at least. Compliance is subjective. It's easier when things make sense. Yes, that is an artifact of the original UNIX implementation on the PDP-11 (16 bit ints, signal number is passed back in one byte, and the return value in another byte). -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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: Why Plan 9 C compilers don't have asm("")
On Tue, Jul 03, 2001 at 11:37:28PM -0400, Rick Hohensee wrote: > That's with the GNU tools, without asm(), and without proper declaration > of printf, as is my tendency. I don't actually return an int either, do I? > LAAETTR. Under ISO C rules, this is illegal, since you must have a proper prototype in scope when calling variable argument functions. In fact, I have worked on several GCC ports, where the compiler uses a different calling sequence for variable argument functions than it does for normal functions. For example, on the Mips, if the first argument is floating point and the number of arguments is not variable, it is passed in a FP register, instead of an integer register. For variable argument functions, everything is passed in the integer registers. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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: Why Plan 9 C compilers don't have asm()
On Tue, Jul 03, 2001 at 11:37:28PM -0400, Rick Hohensee wrote: That's with the GNU tools, without asm(), and without proper declaration of printf, as is my tendency. I don't actually return an int either, do I? LAAETTR. Under ISO C rules, this is illegal, since you must have a proper prototype in scope when calling variable argument functions. In fact, I have worked on several GCC ports, where the compiler uses a different calling sequence for variable argument functions than it does for normal functions. For example, on the Mips, if the first argument is floating point and the number of arguments is not variable, it is passed in a FP register, instead of an integer register. For variable argument functions, everything is passed in the integer registers. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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.
On Tue, Jun 26, 2001 at 11:16:27AM -0400, Rob Landley wrote: > On Monday 25 June 2001 15:23, Kai Henningsen wrote: > > > 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. > > The AS400 seems to be based out of Austin. We hear a lot about it around > here... Ummm, the AS/400 was based out of Rochester, Minnesota at least initially. It was the follow to System/3 -> System/36 -> System/38, and customers originally programmed it in RPG-III and Cobol. Now that AS/400's are based on special PowerPC's, the home may have moved to Austin, which is the PowerPC/AIX center. The AS/400 line was intended to be the mid-range system, between the mainframes (360 -> 370 -> 3080 -> 3900 -> ???) and the PCs. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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: [comphist] Re: Microsoft and Xenix.
On Tue, Jun 26, 2001 at 10:44:53AM -0400, Rob Landley wrote: > Okay, so they're 2.4 megabyte removable cartridges? How big? Are they tapes > or disk packs? (I.E. can you run off of them or are they just storage?) I > know lots of early copies of unix were sent out from Bell Labs on RK05 > cartidges signed "love, ken"... IIRC, rk05 was a removable disk drive, 1 platter to the assembly, about the size of a large pizza box. They were the standard disk drives for small DEC machines of the era. My memories from 30+ years ago, say they were maybe 10 pounds each. I would imagine you are confusing tapes with disks (ie, tk instead of rk) in terms of the release media Bell Labs sent out (at least I never saw a disk with the media, and I did have a job of trying to port the V7 compiler to a V6 system). It could be the very early customers got disks, and the later ones got tapes. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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: [comphist] Re: Microsoft and Xenix.
On Tue, Jun 26, 2001 at 10:44:53AM -0400, Rob Landley wrote: Okay, so they're 2.4 megabyte removable cartridges? How big? Are they tapes or disk packs? (I.E. can you run off of them or are they just storage?) I know lots of early copies of unix were sent out from Bell Labs on RK05 cartidges signed love, ken... IIRC, rk05 was a removable disk drive, 1 platter to the assembly, about the size of a large pizza box. They were the standard disk drives for small DEC machines of the era. My memories from 30+ years ago, say they were maybe 10 pounds each. I would imagine you are confusing tapes with disks (ie, tknum instead of rknum) in terms of the release media Bell Labs sent out (at least I never saw a disk with the media, and I did have a job of trying to port the V7 compiler to a V6 system). It could be the very early customers got disks, and the later ones got tapes. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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.
On Tue, Jun 26, 2001 at 11:16:27AM -0400, Rob Landley wrote: On Monday 25 June 2001 15:23, Kai Henningsen wrote: 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. The AS400 seems to be based out of Austin. We hear a lot about it around here... Ummm, the AS/400 was based out of Rochester, Minnesota at least initially. It was the follow to System/3 - System/36 - System/38, and customers originally programmed it in RPG-III and Cobol. Now that AS/400's are based on special PowerPC's, the home may have moved to Austin, which is the PowerPC/AIX center. The AS/400 line was intended to be the mid-range system, between the mainframes (360 - 370 - 3080 - 3900 - ???) and the PCs. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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: sizeof problem in kernel modules
On Sat, Jun 23, 2001 at 10:43:14PM -0400, Richard B. Johnson wrote: > Previous to the "Draft" "Proposal" of C98, there were no such > requirements. And so-called ANSI -C specifically declined to > define any order within structures. As one of the founding members of the X3J11 ANSI committee, and having served on the committee for 10 1/2 years, I can state categorically that Appendix A of the original K (which was one of the 3 base documents for ANSI C) had the requirement that non-bitfield fields are required to have monotonically increasing addresses (bitfields don't have addresses, and different compiler ABIs do lay them out in different fashions within the words). C89 never changed the wording that mandates this. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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: sizeof problem in kernel modules
On Sat, Jun 23, 2001 at 10:43:14PM -0400, Richard B. Johnson wrote: Previous to the Draft Proposal of C98, there were no such requirements. And so-called ANSI -C specifically declined to define any order within structures. As one of the founding members of the X3J11 ANSI committee, and having served on the committee for 10 1/2 years, I can state categorically that Appendix A of the original KR (which was one of the 3 base documents for ANSI C) had the requirement that non-bitfield fields are required to have monotonically increasing addresses (bitfields don't have addresses, and different compiler ABIs do lay them out in different fashions within the words). C89 never changed the wording that mandates this. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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? (was: Re: accounting for threads)
On Tue, Jun 19, 2001 at 03:38:34PM -0400, Georg Nikodym wrote: > >>>>> "GN" == Georg Nikodym <[EMAIL PROTECTED]> writes: > > >>>>> "MC" == Mike Castle <[EMAIL PROTECTED]> writes: > MC> What about the "UNIX is starting to smell bad" comment? :-> > > GN> I believe that it comes from a paper that Pike presented at a > GN> OSDI (or the Usenix general) last year on the theme of OS > GN> Research being dead. Links to it were also posted on /. around > GN> that time... > > Oops. I was wrong. I found the presentation I was referring to and > it doesn't have this quote. Ummm, the quote about "UNIX is starting to smell bad" is much, much older. I think I first heard in the 1989 Baltimore USENIX, when Pike was the featured speaker, and his talk was "Why workstations don't work", where he outlined Plan9. If it wasn't the Baltimore USENIX, it may have been Salt Lake city, Dallas, or the Boston one. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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? (was: Re: accounting for threads)
On Tue, Jun 19, 2001 at 03:38:34PM -0400, Georg Nikodym wrote: GN == Georg Nikodym [EMAIL PROTECTED] writes: MC == Mike Castle [EMAIL PROTECTED] writes: MC What about the UNIX is starting to smell bad comment? :- GN I believe that it comes from a paper that Pike presented at a GN OSDI (or the Usenix general) last year on the theme of OS GN Research being dead. Links to it were also posted on /. around GN that time... Oops. I was wrong. I found the presentation I was referring to and it doesn't have this quote. Ummm, the quote about UNIX is starting to smell bad is much, much older. I think I first heard in the 1989 Baltimore USENIX, when Pike was the featured speaker, and his talk was Why workstations don't work, where he outlined Plan9. If it wasn't the Baltimore USENIX, it may have been Salt Lake city, Dallas, or the Boston one. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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
On Fri, May 18, 2001 at 03:17:50PM +0100, Stephen C. Tweedie wrote: > Hi, > > On Wed, May 16, 2001 at 12:18:15PM -0400, Michael Meissner wrote: > > > With the current LABEL= support, you won't be able to mount the disks with > > duplicate labels, but you can still mount them via /dev/sd. > > Or you can fall back to mounting by UUID, which is globally unique and > still avoids referencing physical location. You also don't need to > manually set LABELs for UUID to work: all e2fsprogs over the past > couple of years have set UUID on partitions, and e2fsck will create a > new UUID if it sees an old filesystem that doesn't already have one. Presumably, a new UUID is created each time format a partition, which means it is a slight bit of hassle if you have to reload a partition from a dump, or copy a partition to another disk drive. In the scheme of things, it is not a large hassle perhaps, but it is a hassle. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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: CML2 design philosophy heads-up
On Fri, May 18, 2001 at 06:09:09PM +0200, Christoph Hellwig wrote: > Aunt Tillie shouldn't try to manually configure a kernel. Ummm, maybe Aunt Tillie wants to learn how to configure a kernel After all, all of us at one point in time were newbies in terms of configuring kernels, etc. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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: CML2 design philosophy heads-up
On Fri, May 18, 2001 at 06:09:09PM +0200, Christoph Hellwig wrote: Aunt Tillie shouldn't try to manually configure a kernel. Ummm, maybe Aunt Tillie wants to learn how to configure a kernel After all, all of us at one point in time were newbies in terms of configuring kernels, etc. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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
On Thu, May 17, 2001 at 04:46:33AM +0200, Willem Konynenberg wrote: > I think here we might learn from the comments that people made > about how AIX and OSF/1/Tru64 have been doing this. However, I suspect that generally AIX and OSF/1 Tru64 systems come with system managers. Many Linux system do not (well presumably anybody who reads this mailing list has enough of a clue). Also, I bet the number of USB and Firewire devices used on the above two systems is probably vanishingly small. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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 design philosophy heads-up
On Thu, May 17, 2001 at 05:47:41PM +1000, Keith Owens wrote: > On Thu, 17 May 2001 03:26:36 -0400, > "Eric S. Raymond" <[EMAIL PROTECTED]> wrote: > >Pavel Machek <[EMAIL PROTECTED]>: > >> And If I want scsi-on-atapi emulation but not vme147_scsi? > > > >Help me understand this case, please. What is scsi-on-atapi? > >Is SCSI on when you enable it? And is it a realistic case for an SBC? > > SCSI emulation over IDE, CONFIG_BLK_DEV_IDESCSI. You have the SCSI mid > layer code but no SCSI hardware drivers. It is a realistic case for an > embedded CD-RW appliance. Or alternatively, you want to enable SCSI code, with no hardware driver, because you are going to build pcmcia, which builds the scsi drivers only if CONFIG_SCSI is defined, and the user might put in an Adaptec 1460B or 1480 scsi card into your pcmcia slot. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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
On Thu, May 17, 2001 at 04:46:33AM +0200, Willem Konynenberg wrote: I think here we might learn from the comments that people made about how AIX and OSF/1/Tru64 have been doing this. However, I suspect that generally AIX and OSF/1 Tru64 systems come with system managers. Many Linux system do not (well presumably anybody who reads this mailing list has enough of a clue). Also, I bet the number of USB and Firewire devices used on the above two systems is probably vanishingly small. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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 design philosophy heads-up
On Thu, May 17, 2001 at 05:47:41PM +1000, Keith Owens wrote: On Thu, 17 May 2001 03:26:36 -0400, Eric S. Raymond [EMAIL PROTECTED] wrote: Pavel Machek [EMAIL PROTECTED]: And If I want scsi-on-atapi emulation but not vme147_scsi? Help me understand this case, please. What is scsi-on-atapi? Is SCSI on when you enable it? And is it a realistic case for an SBC? SCSI emulation over IDE, CONFIG_BLK_DEV_IDESCSI. You have the SCSI mid layer code but no SCSI hardware drivers. It is a realistic case for an embedded CD-RW appliance. Or alternatively, you want to enable SCSI code, with no hardware driver, because you are going to build pcmcia, which builds the scsi drivers only if CONFIG_SCSI is defined, and the user might put in an Adaptec 1460B or 1480 scsi card into your pcmcia slot. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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: wrong /dev/sd... order with multiple adapters in kernel 2.4.4
On Wed, May 16, 2001 at 01:38:37PM +0200, Massimo Dal Zotto wrote: > Hi, > > I have recently upgraded the kernel from 2.2.19 to 2.4.4 and discovered > that it assigns the /dev/sd... devices in the wrong order with respect both > to the behavior of kernel 2.2.19 and to the `scsihosts' boot option which I > specified at the boot prompt. > > I have a scsi-only machine with an Adaptec 7890 and an old Symbios 53c875. > The Adaptec mounts an LVD disk with the root and home partitions while the > Symbios mounts two additional disks used for other purposes: ... > The only way to solve my problem was to modify the makefiles and link the > aic7xxx driver before the sym53c8xx, but this is a solution only for my > specific case. With my patch the Adaptec is initialized first and I get > a more consistent order of the scsi devices: > > /dev/scsi/host0/bus0/target0/lun0 /dev/sda > /dev/scsi/host1/bus0/target0/lun0 /dev/sdb > /dev/scsi/host1/bus0/target4/lun0 /dev/sdc I had the same problem. The fix that I use is to compile the Symbios driver as a module, and add: alias scsi_hostadapter1 sym53c8xx to my /etc/modules.conf. That way, when the kernel boots, it will only see the Adaptec driver. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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
On Tue, May 15, 2001 at 01:18:09PM -0700, Linus Torvalds wrote: > > On Tue, 15 May 2001, Jonathan Lundell wrote: > > > > > >Keep it informational. And NEVER EVER make it part of the design. > > > > What about: > > > > 1 (network domain). I have two network interfaces that I connect to > > two different network segments, eth0 & eth1; > > So? > > Informational. You can always ask what "eth0" and "eth1" are. > > There's another side to this: repeatability. A setup should be > _repeatable_. > > This is what we have now. Network devices are called "eth0..N", and nobody > is complaining about the fact that the numbering is basically random. It > is _repeatable_ as long as you don't change your hardware setup, and the > numbering has effectively _nothing_ to do with "location". Well yes and no. The numbers are currently repeatable for a given kernel, but I know I and others were bitten by the 2.2. to 2.4 transition, where the kernel used a different algorithm for the order in which it detected scsi and network adapters (ie, in my machine with 3 scsi adapters, Linux 2.2 always picked the Adaptec scsi adapter builtin into my motherboard as the first adapter, but 2.4 decided to pick my TekRam 390F adapter). As lots of people have been saying, you need to know which physical slot to plut the wire connecting eth0, eth1, etc. into. Similarly for serial ports, if I have 3 or 4 (or 127 :-) USB serial devices, I really don't want to have to change my cabling each time I boot or change OSes (since I doubt my UPS will be happy if I give it the commands destined for the X10 controller or my remote boards). -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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
On Wed, May 16, 2001 at 09:30:46AM -0700, Miles Lane wrote: > On 16 May 2001 15:28:03 +0200, Helge Hafting wrote: > > Oystein Viggen wrote: > > > > > > Quoth Helge Hafting: > > > > > > > This could be extended to non-raid use - i.e. use the "raid autodetect" > > > > partition type for non-raid as well. The autodetect routine could > > > > then create /dev/partitions/home, /dev/partitions/usr or > > > > /dev/partitions/name_of_my_choice > > > > for autodetect partitions not participating in a RAID. > > > > > > What happens if I insert a hard drive from another computer which also > > > has partitions named "home", "usr", and soforth? With the current LABEL= support, you won't be able to mount the disks with duplicate labels, but you can still mount them via /dev/sd. Obviously, you need an escape hatch to do this. I ran into this with having two root partitions (to support multiple distributions or releases of distributions), where the distribution automatically uses LABEL=. Fortunately, it was fairly easy to use e2label to fix things up. > > This is the problem with all sorts of ID-based naming. In this case > > the kernel could simply change the conflicting names a bit, > > and leave the cleanup to the administrator. (Who probably > > is around as he just inserted those disks) > > > > The current scheme have problems if you move a disk > > from one controller to another, or in some cases > > if you merely add a new one. So the question becomes - > > what is most likely to go wrong? And you can be > > smart and name your partitions /usr21042001, /home03042001 > > and so on in order to minimize the risk of conflicts. > > Well, a usermode solution might be to add support for having the > filesystem utilities generate and detect partition IDs. Then the disks > could be moved from one controller to another, but mount could scan > partition IDs and associate mount points on matching IDs rather than on > /dev/hdX or /dev/sdX. I don't see how this is any different from the current LABEL= support that is currently in the ext2 filesystem (except I seem to recall that it doesn't work on devfs). Of course it would be useful for /proc/partitions to provide the label IDs and UUIDs. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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
On Wed, May 16, 2001 at 09:30:46AM -0700, Miles Lane wrote: On 16 May 2001 15:28:03 +0200, Helge Hafting wrote: Oystein Viggen wrote: Quoth Helge Hafting: This could be extended to non-raid use - i.e. use the raid autodetect partition type for non-raid as well. The autodetect routine could then create /dev/partitions/home, /dev/partitions/usr or /dev/partitions/name_of_my_choice for autodetect partitions not participating in a RAID. What happens if I insert a hard drive from another computer which also has partitions named home, usr, and soforth? With the current LABEL= support, you won't be able to mount the disks with duplicate labels, but you can still mount them via /dev/sdxxx. Obviously, you need an escape hatch to do this. I ran into this with having two root partitions (to support multiple distributions or releases of distributions), where the distribution automatically uses LABEL=. Fortunately, it was fairly easy to use e2label to fix things up. This is the problem with all sorts of ID-based naming. In this case the kernel could simply change the conflicting names a bit, and leave the cleanup to the administrator. (Who probably is around as he just inserted those disks) The current scheme have problems if you move a disk from one controller to another, or in some cases if you merely add a new one. So the question becomes - what is most likely to go wrong? And you can be smart and name your partitions /usr21042001, /home03042001 and so on in order to minimize the risk of conflicts. Well, a usermode solution might be to add support for having the filesystem utilities generate and detect partition IDs. Then the disks could be moved from one controller to another, but mount could scan partition IDs and associate mount points on matching IDs rather than on /dev/hdX or /dev/sdX. I don't see how this is any different from the current LABEL= support that is currently in the ext2 filesystem (except I seem to recall that it doesn't work on devfs). Of course it would be useful for /proc/partitions to provide the label IDs and UUIDs. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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
On Tue, May 15, 2001 at 01:18:09PM -0700, Linus Torvalds wrote: On Tue, 15 May 2001, Jonathan Lundell wrote: Keep it informational. And NEVER EVER make it part of the design. What about: 1 (network domain). I have two network interfaces that I connect to two different network segments, eth0 eth1; So? Informational. You can always ask what eth0 and eth1 are. There's another side to this: repeatability. A setup should be _repeatable_. This is what we have now. Network devices are called eth0..N, and nobody is complaining about the fact that the numbering is basically random. It is _repeatable_ as long as you don't change your hardware setup, and the numbering has effectively _nothing_ to do with location. Well yes and no. The numbers are currently repeatable for a given kernel, but I know I and others were bitten by the 2.2. to 2.4 transition, where the kernel used a different algorithm for the order in which it detected scsi and network adapters (ie, in my machine with 3 scsi adapters, Linux 2.2 always picked the Adaptec scsi adapter builtin into my motherboard as the first adapter, but 2.4 decided to pick my TekRam 390F adapter). As lots of people have been saying, you need to know which physical slot to plut the wire connecting eth0, eth1, etc. into. Similarly for serial ports, if I have 3 or 4 (or 127 :-) USB serial devices, I really don't want to have to change my cabling each time I boot or change OSes (since I doubt my UPS will be happy if I give it the commands destined for the X10 controller or my remote boards). -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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: wrong /dev/sd... order with multiple adapters in kernel 2.4.4
On Wed, May 16, 2001 at 01:38:37PM +0200, Massimo Dal Zotto wrote: Hi, I have recently upgraded the kernel from 2.2.19 to 2.4.4 and discovered that it assigns the /dev/sd... devices in the wrong order with respect both to the behavior of kernel 2.2.19 and to the `scsihosts' boot option which I specified at the boot prompt. I have a scsi-only machine with an Adaptec 7890 and an old Symbios 53c875. The Adaptec mounts an LVD disk with the root and home partitions while the Symbios mounts two additional disks used for other purposes: ... The only way to solve my problem was to modify the makefiles and link the aic7xxx driver before the sym53c8xx, but this is a solution only for my specific case. With my patch the Adaptec is initialized first and I get a more consistent order of the scsi devices: /dev/scsi/host0/bus0/target0/lun0 /dev/sda /dev/scsi/host1/bus0/target0/lun0 /dev/sdb /dev/scsi/host1/bus0/target4/lun0 /dev/sdc I had the same problem. The fix that I use is to compile the Symbios driver as a module, and add: alias scsi_hostadapter1 sym53c8xx to my /etc/modules.conf. That way, when the kernel boots, it will only see the Adaptec driver. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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
On Mon, May 14, 2001 at 06:01:42PM +0100, Alan Cox wrote: > > IIRC, the 6 character linker requirement came from when the Bell Labs folk > > ported the C compiler the IBM mainframe world, not from the early UNIX (tm) > > world. During the original ANSI C meetings, I got the sense from the IBM rep, > > 6 character linker name limits are very old. Honeywell L66 GCOS3/TSS which I > had the dubious pleasure of experiencing and which is a direct derivative of > GECOS and thus relevant to the era like many 36bit boxes uses 6 char link names > > Why - well because 6 BCD characters fit in a 36bit word and its a single compare > to check symbol matches Another old system that I recall was the CDC Cyber systems, which when I encountered them used 6-bit 'bytes' (the null byte meaning ':' in some cases, and null in others). The linker resolved names to 7 characters, so it could fit the name (42 bits) + an 18 bit address into a single 60 bit word. One of the most useful rules of the GNU coding standards is that it asks people to avoid putting arbitrary limits in their code: For example, Unix utilities were generally optimized to minimize memory use; if you go for speed instead, your program will be very different. You could keep the entire input file in core and scan it there instead of using stdio. Use a smarter algorithm discovered more recently than the Unix program. Eliminate use of temporary files. Do it in one pass instead of two (we did this in the assembler). Or, on the contrary, emphasize simplicity instead of speed. For some applications, the speed of today's computers makes simpler algorithms adequate. Or go for generality. For example, Unix programs often have static tables or fixed-size strings, which make for arbitrary limits; use dynamic allocation instead. Make sure your program handles NULs and other funny characters in the input files. Add a programming language for extensibility and write part of the program in that language. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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 typewriterg
On Mon, May 14, 2001 at 10:31:48AM -0400, John Kodis wrote: > On Sun, May 13, 2001 at 09:03:30PM -0400, Horst von Brand wrote: > > > The old C compiler/old Unix linker guaranteed 6 chars in an external symbol > > name only, and C functions got an underscore prepended: _creat. I guess > > this is the reason for this wart. As to why 6 chars only, I'd guess some > > data structure in the linker was laid out that way. Machines had a few > > dozen Kbs of RAM then, space was precious. > > I recall that RSX-11 and a few other series of early DEC operating > systems stored linker symbols in a "RAD50" encoding scheme which > allowed 6 chararacters to be crammed into a 32-bit "long word". I > suspect that this is where the limitation originated. More trivia. Rad50 actually allows 5 characters per 32-bit word. The 50 is actually 050 in octal (ie, 40 decimal), and allows you to have all 26 english letters, 10 digits, a null, and 3 characters. At this stage, I don't remember what the precise encoding is, or what the additional 3 characters were (I suspect different systems used different characters). One of the first systems I worked on professionally (Data General RDOS) used RAD50 in their object file format. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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
On Sun, May 13, 2001 at 09:03:30PM -0400, Horst von Brand wrote: > "Mike A. Harris" <[EMAIL PROTECTED]> said: > > On Fri, 11 May 2001 [EMAIL PROTECTED] wrote: > > [...] > > > >why creat doesn't end in an "e;" and so forth. I tell the > > The old C compiler/old Unix linker guaranteed 6 chars in an external symbol > name only, and C functions got an underscore prepended: _creat. I guess > this is the reason for this wart. As to why 6 chars only, I'd guess some > data structure in the linker was laid out that way. Machines had a few > dozen Kbs of RAM then, space was precious. IIRC, the 6 character linker requirement came from when the Bell Labs folk ported the C compiler the IBM mainframe world, not from the early UNIX (tm) world. During the original ANSI C meetings, I got the sense from the IBM rep, that part of the problem was the linker was owned by the OS folk, and not the language group, and it was hard to make a business case why the linker should be extended to handle newer languages (since it was a different office that was responsible). The 6 character limit came from the fact that the linker actually supported 8 characters, but the first 2 characters were used to denote different products (I recall IBM stuff all tended to be IE). The VMS folk also had a similar problem (but there they had a 31 character, one case limit), though by the end of the process, the linker had been moved into the languages group in that case. The mainframe linker is also why the 1989 C standard required there to be only one definition of a global variable (ie, only one module can say "int x;" while others must say "extern int x"), even though the UNIX compilers have traditionally used the common model (ie, "int x" creates a common relocation, so that if there is no other non-common definition, the linker will create one). Evidently, the mainframe linker decided to put each unique common variable on its own page. I vaguelly recall that somebody went back to Ritchie & Thompson and asked if they could go back in time and make one change, what would it be. Ritchie's answer was to make default chars be unsigned instead of signed (since it really messes up internation character support), and Thompson's answer was to spell "create" with an trailing e. > > What is the reason for that? Also wondered why it is resolv.conf > > and not resolve.conf or resolver.conf... > > Old FS handled only 14 chars in names, but that clearly isn't the reason > here (11 chars). Some other operating system perhaps? I would imagine you should ask the Berkely folks, since the TCP/IP support all came from there, and not Bell Labs. > > Were they afraid that "e" being the most widely used letter in > > the English language was going to war out thir xpnsiv kyboards if > > thy usd it all th tim? > > Funny conspiracy suscpicion, that... ;-) -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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
On Sun, May 13, 2001 at 09:03:30PM -0400, Horst von Brand wrote: Mike A. Harris [EMAIL PROTECTED] said: On Fri, 11 May 2001 [EMAIL PROTECTED] wrote: [...] why creat doesn't end in an e; and so forth. I tell the The old C compiler/old Unix linker guaranteed 6 chars in an external symbol name only, and C functions got an underscore prepended: _creat. I guess this is the reason for this wart. As to why 6 chars only, I'd guess some data structure in the linker was laid out that way. Machines had a few dozen Kbs of RAM then, space was precious. IIRC, the 6 character linker requirement came from when the Bell Labs folk ported the C compiler the IBM mainframe world, not from the early UNIX (tm) world. During the original ANSI C meetings, I got the sense from the IBM rep, that part of the problem was the linker was owned by the OS folk, and not the language group, and it was hard to make a business case why the linker should be extended to handle newer languages (since it was a different office that was responsible). The 6 character limit came from the fact that the linker actually supported 8 characters, but the first 2 characters were used to denote different products (I recall IBM stuff all tended to be IE). The VMS folk also had a similar problem (but there they had a 31 character, one case limit), though by the end of the process, the linker had been moved into the languages group in that case. The mainframe linker is also why the 1989 C standard required there to be only one definition of a global variable (ie, only one module can say int x; while others must say extern int x), even though the UNIX compilers have traditionally used the common model (ie, int x creates a common relocation, so that if there is no other non-common definition, the linker will create one). Evidently, the mainframe linker decided to put each unique common variable on its own page. I vaguelly recall that somebody went back to Ritchie Thompson and asked if they could go back in time and make one change, what would it be. Ritchie's answer was to make default chars be unsigned instead of signed (since it really messes up internation character support), and Thompson's answer was to spell create with an trailing e. What is the reason for that? Also wondered why it is resolv.conf and not resolve.conf or resolver.conf... Old FS handled only 14 chars in names, but that clearly isn't the reason here (11 chars). Some other operating system perhaps? I would imagine you should ask the Berkely folks, since the TCP/IP support all came from there, and not Bell Labs. Were they afraid that e being the most widely used letter in the English language was going to war out thir xpnsiv kyboards if thy usd it all th tim? Funny conspiracy suscpicion, that... ;-) -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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 typewriterg
On Mon, May 14, 2001 at 10:31:48AM -0400, John Kodis wrote: On Sun, May 13, 2001 at 09:03:30PM -0400, Horst von Brand wrote: The old C compiler/old Unix linker guaranteed 6 chars in an external symbol name only, and C functions got an underscore prepended: _creat. I guess this is the reason for this wart. As to why 6 chars only, I'd guess some data structure in the linker was laid out that way. Machines had a few dozen Kbs of RAM then, space was precious. I recall that RSX-11 and a few other series of early DEC operating systems stored linker symbols in a RAD50 encoding scheme which allowed 6 chararacters to be crammed into a 32-bit long word. I suspect that this is where the limitation originated. More trivia. Rad50 actually allows 5 characters per 32-bit word. The 50 is actually 050 in octal (ie, 40 decimal), and allows you to have all 26 english letters, 10 digits, a null, and 3 characters. At this stage, I don't remember what the precise encoding is, or what the additional 3 characters were (I suspect different systems used different characters). One of the first systems I worked on professionally (Data General RDOS) used RAD50 in their object file format. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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
On Mon, May 14, 2001 at 06:01:42PM +0100, Alan Cox wrote: IIRC, the 6 character linker requirement came from when the Bell Labs folk ported the C compiler the IBM mainframe world, not from the early UNIX (tm) world. During the original ANSI C meetings, I got the sense from the IBM rep, 6 character linker name limits are very old. Honeywell L66 GCOS3/TSS which I had the dubious pleasure of experiencing and which is a direct derivative of GECOS and thus relevant to the era like many 36bit boxes uses 6 char link names Why - well because 6 BCD characters fit in a 36bit word and its a single compare to check symbol matches Another old system that I recall was the CDC Cyber systems, which when I encountered them used 6-bit 'bytes' (the null byte meaning ':' in some cases, and null in others). The linker resolved names to 7 characters, so it could fit the name (42 bits) + an 18 bit address into a single 60 bit word. One of the most useful rules of the GNU coding standards is that it asks people to avoid putting arbitrary limits in their code: For example, Unix utilities were generally optimized to minimize memory use; if you go for speed instead, your program will be very different. You could keep the entire input file in core and scan it there instead of using stdio. Use a smarter algorithm discovered more recently than the Unix program. Eliminate use of temporary files. Do it in one pass instead of two (we did this in the assembler). Or, on the contrary, emphasize simplicity instead of speed. For some applications, the speed of today's computers makes simpler algorithms adequate. Or go for generality. For example, Unix programs often have static tables or fixed-size strings, which make for arbitrary limits; use dynamic allocation instead. Make sure your program handles NULs and other funny characters in the input files. Add a programming language for extensibility and write part of the program in that language. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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: Linux 2.4.3ac13
On Tue, Apr 24, 2001 at 07:36:42PM -0400, Johannes Erdfelt wrote: > On Tue, Apr 24, 2001, Michael Meissner <[EMAIL PROTECTED]> wrote: > > and it doesn't ask whether I want to build the normal USHI USB driver either as > > a module or builtin to the kernel, only whether I want to build the alternative > > USHI USB dirver (the JE driver). Make xconfig asks whether you want to build > > both drivers. I'm not sure whether this was a bug in previous versions or > > not. > > That's probably because you selected the alternative UHCI driver to > build into the kernel. In that case, the other UHCI driver is not > available as an option anymore. If you select it as a module, then both > will be available. Ummm, no. As I said, I first cleaned everything out with mrproper, and then went through the options in order. Since the alternative UHCI driver does not occur until after the question for the normal UHCI driver in drivers/usb/Configure.in, it never asked me the question of building the normal UHCI driver. I just verified that if I use make xconfig instead of make menuconfig, I will be able to choose either driver (yes, if you choose one as builtin, it won't allow you to choose the other, but I'm talking about building them as modules, and the initial selection after make mrproper is done). -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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: Linux 2.4.3ac13
On Tue, Apr 24, 2001 at 01:14:11AM +0100, Alan Cox wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ > > Intermediate diffs are available from > > http://www.bzimage.org > > This isnt a proper release as such, it should just deal with most of the > compile failure/symbol failure problems. > > 2.4.3-ac13 > o Switch to NOVERS symbols for rwsem (me) > | Called from asm blocks so they can't be versioned > o Fix gcc 2.95 building on rwsem (Niels Jensen) > o Fix cmsfs build (Andrzej Krzysztofowicz) > o Fix rio build/HZ setup (Andrzej Krzysztofowicz) > o Fix PPP filtering dependancy in config (Andrzej Krzysztofowicz) I just tried 2.4.3-ac13 on my laptop, a Toshiba Tecra 8000, which has a NeoMagic video controller. I boot it using the VESA frame buffer, using the arguments: video=vesa:mtrr vga=0x317 for a 16-bit 1024x768 screen. The video doesn't come on at all, but the machine boots up normally (ie, I can log into it via ssh via the wireless pcmcia card). If I boot up with the VGA console, the screen is displayed just fine. This worked in 2.4.3-ac11. Also, I initially built ac13 with: make mrproper make menuconfig and it doesn't ask whether I want to build the normal USHI USB driver either as a module or builtin to the kernel, only whether I want to build the alternative USHI USB dirver (the JE driver). Make xconfig asks whether you want to build both drivers. I'm not sure whether this was a bug in previous versions or not. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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: i386 cleanups
On Tue, Apr 17, 2001 at 02:46:09PM -0700, Linus Torvalds wrote: > > > On Tue, 17 Apr 2001, Pavel Machek wrote: > > > > These are tiny cleanups you might like. sizes are "logically" > > long. > > No. Sizes are not "logical". They are whatever you decide they are, ie > it's purely a complier convention. Not purely a compiler convention, but an ABI requirement. In particular, Linux GCC adheres to the ABI specified in the System V UNIX Intel386 (tm) Processor Supplement, and on page 6-66, in figure 6-70, the specification for stddef.h says that: typedef int ptrdiff_t; typedef unsigned int size_t; typedef long wchar_t; > At least earlier, size_t was defined as "unsigned int" in user mode, and > doing anything else would make gcc complain about clashes with its > compiled-in __builtin_size_t that it uses for the builtin prototypes (ie > if you had a declaration for "void *memcpy(void *dest, const void *src, > size_t n);" and your size_t didn't match the gcc builtin_size_t, you'd get > a "redefined with different arguments" warning or something). While, I grant that this is one area the ABI could have been improved upon (alignment of floating point, and reservation of EBX as GOT pointers are other sore spots), it is the ABI of record. Yes, we could certainly choose a different ABI for Linux, but it is probably too late for that in the case of the x86. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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: i386 cleanups
On Tue, Apr 17, 2001 at 02:46:09PM -0700, Linus Torvalds wrote: On Tue, 17 Apr 2001, Pavel Machek wrote: These are tiny cleanups you might like. sizes are "logically" long. No. Sizes are not "logical". They are whatever you decide they are, ie it's purely a complier convention. Not purely a compiler convention, but an ABI requirement. In particular, Linux GCC adheres to the ABI specified in the System V UNIX Intel386 (tm) Processor Supplement, and on page 6-66, in figure 6-70, the specification for stddef.h says that: typedef int ptrdiff_t; typedef unsigned int size_t; typedef long wchar_t; At least earlier, size_t was defined as "unsigned int" in user mode, and doing anything else would make gcc complain about clashes with its compiled-in __builtin_size_t that it uses for the builtin prototypes (ie if you had a declaration for "void *memcpy(void *dest, const void *src, size_t n);" and your size_t didn't match the gcc builtin_size_t, you'd get a "redefined with different arguments" warning or something). While, I grant that this is one area the ABI could have been improved upon (alignment of floating point, and reservation of EBX as GOT pointers are other sore spots), it is the ABI of record. Yes, we could certainly choose a different ABI for Linux, but it is probably too late for that in the case of the x86. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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: How do I make a circular pipe?
ue from `unlockpt' is 0; a value of -1 is
returned in case of failure. The following `errno' error
conditions are defined for this function:
`EBADF'
The FILEDES argument is not a valid file descriptor.
`EINVAL'
The FILEDES argument is not associated with a master
pseudo-terminal device.
- Function: char * ptsname (int FILEDES)
If the file descriptor FILEDES is associated with a master
pseudo-terminal device, the `ptsname' function returns a pointer
to a statically-allocated, null-terminated string containing the
file name of the associated slave pseudo-terminal file. This
string might be overwritten by subsequent calls to `ptsname'.
- Function: int ptsname_r (int FILEDES, char *BUF, size_t LEN)
The `ptsname_r' function is similar to the `ptsname' function
except that it places its result into the user-specified buffer
starting at BUF with length LEN.
This function is a GNU extension.
*Portability Note:* On System V derived systems, the file returned
by the `ptsname' and `ptsname_r' functions may be STREAMS-based, and
therefore require additional processing after opening before it
actually behaves as a pseudo terminal.
therefore require additional processing after opening before it
actually behaves as a pseudo terminal.
Typical usage of these functions is illustrated by the following
example:
int
open_pty_pair (int *amaster, int *aslave)
{
int master, slave;
char *name;
master = getpt ();
if (master < 0)
return 0;
if (grantpt (master) < 0 || unlockpt (master) < 0)
goto close_master;
name = ptsname (master);
if (name == NULL)
goto close_master;
slave = open (name, O_RDWR);
if (slave == -1)
goto close_master;
if (isastream (slave))
{
if (ioctl (slave, I_PUSH, "ptem") < 0
|| ioctl (slave, I_PUSH, "ldterm") < 0)
goto close_slave;
}
*amaster = master;
*aslave = slave;
return 1;
close_slave:
close (slave);
close_master:
close (master);
return 0;
}
--
Michael Meissner, Red Hat, Inc. (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: [EMAIL PROTECTED] phone: +1 978-486-9304
Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482
-
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: How do I make a circular pipe?
for this function:
`EBADF'
The FILEDES argument is not a valid file descriptor.
`EINVAL'
The FILEDES argument is not associated with a master
pseudo-terminal device.
- Function: char * ptsname (int FILEDES)
If the file descriptor FILEDES is associated with a master
pseudo-terminal device, the `ptsname' function returns a pointer
to a statically-allocated, null-terminated string containing the
file name of the associated slave pseudo-terminal file. This
string might be overwritten by subsequent calls to `ptsname'.
- Function: int ptsname_r (int FILEDES, char *BUF, size_t LEN)
The `ptsname_r' function is similar to the `ptsname' function
except that it places its result into the user-specified buffer
starting at BUF with length LEN.
This function is a GNU extension.
*Portability Note:* On System V derived systems, the file returned
by the `ptsname' and `ptsname_r' functions may be STREAMS-based, and
therefore require additional processing after opening before it
actually behaves as a pseudo terminal.
therefore require additional processing after opening before it
actually behaves as a pseudo terminal.
Typical usage of these functions is illustrated by the following
example:
int
open_pty_pair (int *amaster, int *aslave)
{
int master, slave;
char *name;
master = getpt ();
if (master 0)
return 0;
if (grantpt (master) 0 || unlockpt (master) 0)
goto close_master;
name = ptsname (master);
if (name == NULL)
goto close_master;
slave = open (name, O_RDWR);
if (slave == -1)
goto close_master;
if (isastream (slave))
{
if (ioctl (slave, I_PUSH, "ptem") 0
|| ioctl (slave, I_PUSH, "ldterm") 0)
goto close_slave;
}
*amaster = master;
*aslave = slave;
return 1;
close_slave:
close (slave);
close_master:
close (master);
return 0;
}
--
Michael Meissner, Red Hat, Inc. (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: [EMAIL PROTECTED] phone: +1 978-486-9304
Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482
-
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: Linux 2.4.2ac13
Just a note -- the change in ac4 and beyond to the new aic7xxx scsi driver and move Doug Ledford's now non-supported driver to aic7xxx-old breaks the pcmcia 3.1.24 release if you configure scsi device support into the kernel. The aic7xxx driver is used to support the Adpatec 1480 scsi card. I have a 1460 scsi card, so I build my laptop release with scsi support included. I'll post this also to the pcmcia support pages. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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: Linux 2.4.2ac13
Just a note -- the change in ac4 and beyond to the new aic7xxx scsi driver and move Doug Ledford's now non-supported driver to aic7xxx-old breaks the pcmcia 3.1.24 release if you configure scsi device support into the kernel. The aic7xxx driver is used to support the Adpatec 1480 scsi card. I have a 1460 scsi card, so I build my laptop release with scsi support included. I'll post this also to the pcmcia support pages. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - 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: Linux not adhering to BIOS Drive boot order?
On Tue, Jan 16, 2001 at 08:14:01PM -0600, Peter Samuelson wrote: > > [Michael Meissner] > > Ummm, I just reread the 2.4 Changes file once again just to be sure, > > and it did not cover this issue. So how the *$@% are people supposed > > to "read some docs" to know about this, if the docs don't mention the > > information. I know people have been complaining about this change > > since at least the fall time frame. > > SCSI host probe order has never been guaranteed, afaik -- this is not > new to 2.4. If you have multiple host adapters, you really need to use > the command line to say which is which, as always. If you don't, you > will be bitten eventually. > > "Eventually" in this case meant 2.2->2.4, perhaps, but that doesn't > make it an item for Documentation/Changes. Or is this not what you > were talking about? What I'm talking about is that whenever you have these flag day(*) type of operations, is weakens the whole Linux movement. Yes, each individual change might mean a few minutes to half an hour of a persons time, but cumulatively it just sends the signal that Linux is just a hackers toy. If people can't easily switch between kernels for instance due to the wrong disk being listed as the boot disk, or they have to replug which ethernet controller gets which cord, it will mean fewer people testing new kernels for instance. * http://www.tuxedo.org/~esr/jargon/html/entry/flag-day.html -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
On Tue, Jan 16, 2001 at 08:14:01PM -0600, Peter Samuelson wrote: [Michael Meissner] Ummm, I just reread the 2.4 Changes file once again just to be sure, and it did not cover this issue. So how the *$@% are people supposed to "read some docs" to know about this, if the docs don't mention the information. I know people have been complaining about this change since at least the fall time frame. SCSI host probe order has never been guaranteed, afaik -- this is not new to 2.4. If you have multiple host adapters, you really need to use the command line to say which is which, as always. If you don't, you will be bitten eventually. "Eventually" in this case meant 2.2-2.4, perhaps, but that doesn't make it an item for Documentation/Changes. Or is this not what you were talking about? What I'm talking about is that whenever you have these flag day(*) type of operations, is weakens the whole Linux movement. Yes, each individual change might mean a few minutes to half an hour of a persons time, but cumulatively it just sends the signal that Linux is just a hackers toy. If people can't easily switch between kernels for instance due to the wrong disk being listed as the boot disk, or they have to replug which ethernet controller gets which cord, it will mean fewer people testing new kernels for instance. * http://www.tuxedo.org/~esr/jargon/html/entry/flag-day.html -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
On Wed, Jan 17, 2001 at 12:32:05AM +0100, J . A . Magallon wrote: > If that is your idea of the average user... You're a system administrator, > you can have tons of scsi cards in your system if you want. > > You want to make things SOOO easy for a 'dummy' user, and that user will never > use them. The average user you are targetting says: 'daddy, buy me a PC to > run Quake and do my school jobs' or 'please, dear vendor, I want a PC to > do my housekeeping'. I have seen so many cases (A buys PC, A tries to run > brand new racing game that does not work, A goes shop and says: don't know > what's wrong with this PC, look at it and call me when MyCarRacingGame > works...). I also don't want things so complex for the people who need to do complex things, that they give up in frustration with Linux and use something else like *BSD, particularly when things are changed from the previous way they were done in Linux. I agree things should be simple for simple configurations, but that does not mean we should be throwing boat anchors and couches in the paths of people who have more complex hardware. > Average users you are targetting with that automagical > card detection even do not know there are SCSI and IDE disks. They just > want a 30Gb ide disk to install linux and play. If they involve with SCSI > and ID numbers and multiple cards and so on they can read some docs and > rebuild a kernel. Ummm, I just reread the 2.4 Changes file once again just to be sure, and it did not cover this issue. So how the *$@% are people supposed to "read some docs" to know about this, if the docs don't mention the information. I know people have been complaining about this change since at least the fall time frame. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
On Tue, Jan 16, 2001 at 10:01:25PM +0100, Andi Kleen wrote: > On Tue, Jan 16, 2001 at 03:37:57PM -0500, Michael Meissner wrote: > > don't assume that the way your system gets booted is the way everybody's does, > > particularly those on platforms other than the x86. > > > > I must say, as a 5 year Linux user (and 23 year UNIX user/administrator), I do > > get tired of having to hunt down and deal with each of these changes that come > > up from time to time with Linux (ie, switching from ipfwadm to ipchains to > > netfilter, or in this case reordering how scsi adapters/network adapters are > > looked up). > > Bad example. > > netfilter does not force you to switch anything. You can just load the ipchains > or even the ipfw module and use your old scripts. Granted I was mainly thinking of the ipfwadm->ipchains conversion, but you have to root around and load the appropriate module. I like to build as much into the kernel as possible, and it took some amount of time to get things so that I could build the ipchains modules, since you are presented with choices that preclude building of the modules. If I had been using make config instead of make xconfig, it would have been worse, since I would have to go through the questions each time to get to the network section. I could also use the various incompatible transforms MD support has had over the years for another example, or the number of times system status monitors break due to changes in the output of /proc files (and yes I grant you many of the changes are due to poor programming in the status programs, but not all of them). Yes, change is one of the things that makes Linux strong. However, change to the way things are done can piss people off to using an alternate system, such as happened to Sun when they changed from the BSD method of system administration to System V many years ago. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
On Tue, Jan 16, 2001 at 12:01:12PM -0800, Dr. Kelsey Hudson wrote: > On Tue, 16 Jan 2001, Venkatesh Ramamurthy wrote: > > > > This is due to the fixed ordering of the scsi drivers. You can change the > > > order of the scsi hosts with the "scsihosts" kernel parameter. See > > > linux/drivers/scsi/scsi.c > > [Venkatesh Ramamurthy] I think it would be a nice idea if we can > > make this process automatic , with out user typing in the order and > > remembering it. The fact that a kernel developer is not using the machines > > daily to get his work done should be in our minds. If we do this Linux would > > become more user friendly > > you're forgetting that in /etc/lilo.conf there is a directive called > 'append='... all the user has to do is merely add > 'append="scsihosts=whatever,whatever"' into their config file and rerun > lilo. problem solved That's assuming you are using lilo. Not everybody does or can use lilo, please don't assume that the way your system gets booted is the way everybody's does, particularly those on platforms other than the x86. I must say, as a 5 year Linux user (and 23 year UNIX user/administrator), I do get tired of having to hunt down and deal with each of these changes that come up from time to time with Linux (ie, switching from ipfwadm to ipchains to netfilter, or in this case reordering how scsi adapters/network adapters are looked up). > besides, how many 'end-users' do you know of that will have multiple scsi > adapters in one system? how many end-users -period- will have even a > *single* scsi adapter in their systems? do we need to bloat the kernel > with automatic things like this? no... i think it is handled fine the way > it is. if the user wants to add more than one scsi adapter into his > system, let him read some documentation on how to do so. (is this even a > documented feature? if not, i think it should be added to the docs...) I'm an end-user, and I have 3 scsi-adapters of two different brands in my system. Many of the people using Linux in high end things like servers, etc. will have multiple scsi controlers. People are using Linux in lots of things from small embedded devices to large systems, and Linux needs to address needs in every area. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
On Tue, Jan 16, 2001 at 10:01:25PM +0100, Andi Kleen wrote: On Tue, Jan 16, 2001 at 03:37:57PM -0500, Michael Meissner wrote: don't assume that the way your system gets booted is the way everybody's does, particularly those on platforms other than the x86. I must say, as a 5 year Linux user (and 23 year UNIX user/administrator), I do get tired of having to hunt down and deal with each of these changes that come up from time to time with Linux (ie, switching from ipfwadm to ipchains to netfilter, or in this case reordering how scsi adapters/network adapters are looked up). Bad example. netfilter does not force you to switch anything. You can just load the ipchains or even the ipfw module and use your old scripts. Granted I was mainly thinking of the ipfwadm-ipchains conversion, but you have to root around and load the appropriate module. I like to build as much into the kernel as possible, and it took some amount of time to get things so that I could build the ipchains modules, since you are presented with choices that preclude building of the modules. If I had been using make config instead of make xconfig, it would have been worse, since I would have to go through the questions each time to get to the network section. I could also use the various incompatible transforms MD support has had over the years for another example, or the number of times system status monitors break due to changes in the output of /proc files (and yes I grant you many of the changes are due to poor programming in the status programs, but not all of them). Yes, change is one of the things that makes Linux strong. However, change to the way things are done can piss people off to using an alternate system, such as happened to Sun when they changed from the BSD method of system administration to System V many years ago. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
On Tue, Jan 16, 2001 at 12:01:12PM -0800, Dr. Kelsey Hudson wrote: On Tue, 16 Jan 2001, Venkatesh Ramamurthy wrote: This is due to the fixed ordering of the scsi drivers. You can change the order of the scsi hosts with the "scsihosts" kernel parameter. See linux/drivers/scsi/scsi.c [Venkatesh Ramamurthy] I think it would be a nice idea if we can make this process automatic , with out user typing in the order and remembering it. The fact that a kernel developer is not using the machines daily to get his work done should be in our minds. If we do this Linux would become more user friendly you're forgetting that in /etc/lilo.conf there is a directive called 'append='... all the user has to do is merely add 'append="scsihosts=whatever,whatever"' into their config file and rerun lilo. problem solved That's assuming you are using lilo. Not everybody does or can use lilo, please don't assume that the way your system gets booted is the way everybody's does, particularly those on platforms other than the x86. I must say, as a 5 year Linux user (and 23 year UNIX user/administrator), I do get tired of having to hunt down and deal with each of these changes that come up from time to time with Linux (ie, switching from ipfwadm to ipchains to netfilter, or in this case reordering how scsi adapters/network adapters are looked up). besides, how many 'end-users' do you know of that will have multiple scsi adapters in one system? how many end-users -period- will have even a *single* scsi adapter in their systems? do we need to bloat the kernel with automatic things like this? no... i think it is handled fine the way it is. if the user wants to add more than one scsi adapter into his system, let him read some documentation on how to do so. (is this even a documented feature? if not, i think it should be added to the docs...) I'm an end-user, and I have 3 scsi-adapters of two different brands in my system. Many of the people using Linux in high end things like servers, etc. will have multiple scsi controlers. People are using Linux in lots of things from small embedded devices to large systems, and Linux needs to address needs in every area. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
On Wed, Jan 17, 2001 at 12:32:05AM +0100, J . A . Magallon wrote: If that is your idea of the average user... You're a system administrator, you can have tons of scsi cards in your system if you want. You want to make things SOOO easy for a 'dummy' user, and that user will never use them. The average user you are targetting says: 'daddy, buy me a PC to run Quake and do my school jobs' or 'please, dear vendor, I want a PC to do my housekeeping'. I have seen so many cases (A buys PC, A tries to run brand new racing game that does not work, A goes shop and says: don't know what's wrong with this PC, look at it and call me when MyCarRacingGame works...). I also don't want things so complex for the people who need to do complex things, that they give up in frustration with Linux and use something else like *BSD, particularly when things are changed from the previous way they were done in Linux. I agree things should be simple for simple configurations, but that does not mean we should be throwing boat anchors and couches in the paths of people who have more complex hardware. Average users you are targetting with that automagical card detection even do not know there are SCSI and IDE disks. They just want a 30Gb ide disk to install linux and play. If they involve with SCSI and ID numbers and multiple cards and so on they can read some docs and rebuild a kernel. Ummm, I just reread the 2.4 Changes file once again just to be sure, and it did not cover this issue. So how the *$@% are people supposed to "read some docs" to know about this, if the docs don't mention the information. I know people have been complaining about this change since at least the fall time frame. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: The advantage of modules?
On Mon, Jan 08, 2001 at 07:26:01PM +0100, Ookhoi wrote: > >3) Having drivers as modules means that you can remove them and > >reload them. When I was working in an office, I had one scsi > >controller that was a different brand (Adaptec) than the main scsi > >controller (TekRam), and I hung a disk in a removable chasis on the > >scsi chain in addition to a tape driver and cd-rom. When I was > >about to go home, I would copy all of the data to the disk, unmount > >it, and then unload the scsi device driver. I would take the disk > >out, and reload the scsi device driver to get the tape/cd-rom. I > >would then take the disk to my home computer. I would reverse the > >process when I came in the morning. > > You don't need modules for this to work. Quoting from drivers/scsi/scsi.c: /* * Usage: echo "scsi add-single-device 0 1 2 3" >/proc/scsi/scsi * with "0 1 2 3" replaced by your "Host Channel Id Lun". * Consider this feature BETA. * CAUTION: This is not for hotplugging your peripherals. As * SCSI was not designed for this you could damage your * hardware ! * However perhaps it is legal to switch on an * already connected device. It is perhaps not * guaranteed this device doesn't corrupt an ongoing data transfer. */ so my take is unless you explicitly use hotplug devices (I wasn't), that it is much safer to unload the driver, unattach/attach scsi devices, and then reload the driver (which will scan the scsi bus for devices), which you need modules for. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: The advantage of modules?
On Fri, Jan 05, 2001 at 10:50:20PM -0600, Evan Thompson wrote:
> I'd like to know (I know, I'm being slightly off topic, while still
> staying on topic, so I'm on topic...er...yes) if there is any
> advantage, be it memory-wise or architectuarally wise, to use modules?
>
> I already know the obvious points of if you are creating a distro that
> it is usually good to make a very modular kernel for those wishing not
> to recompile their kernel, but I was wondering if there were any other
> advantages to using modules vs. making a monolithic kernel for a
> kernel to be used only on one machine (with no other hardware support
> at all)?
A couple of thoughts:
1) A full kernel with everything compiled in might not fit on boot media
such as floppies, while modules allows you to not load stuff that isn't
needed to until after the main booting is accomplished.
2) There are several devices that have multiple drivers (such as tulip,
and old_tulip for example). Which particular driver works depends on
your exact particular hardware. If both of these drivers are linked
into the kernel, whatever the kernel chooses to initialize first will
talk to the device.
3) Having drivers as modules means that you can remove them and reload
them. When I was working in an office, I had one scsi controller that
was a different brand (Adaptec) than the main scsi controller (TekRam),
and I hung a disk in a removable chasis on the scsi chain in addition
to a tape driver and cd-rom. When I was about to go home, I would copy
all of the data to the disk, unmount it, and then unload the scsi
device driver. I would take the disk out, and reload the scsi device
driver to get the tape/cd-rom. I would then take the disk to my home
computer. I would reverse the process when I came in the morning.
4) If you have multiple scsi controllers of different brands, building on
into the kernel and the other brand(s) as modules allows you to control
which scsi controller is the first controller in terms of where the
disks are.
--
Michael Meissner, Red Hat, Inc. (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: [EMAIL PROTECTED] phone: +1 978-486-9304
Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: The advantage of modules?
On Sat, Jan 06, 2001 at 11:02:15AM +0100, J . A . Magallon wrote: > > On 2001.01.06 Drew Bertola wrote: > > My best reasons are... > > > > Development: You don't have to recompile the kernel a billion times > > while working on a driver, you just recompile the module. Also, you > > can debug, unload, fix, recompile, reload a module to add or fix > > pieces of it all (hopefully) without rebooting. > > > > Practical usage: When I take my laptop on the road I use ppp, so I > > load it then. Most of the time I don't need it, so I don't load it. > > > > Usage: I have seen drivers which require params to work, and you can > only give params if the driver is built as a module (ie, > modprobe xx io=0x300 irq=5, etc...) because your hard is not > properly autodetected by the module. For many devices you can specify the parameters at boot time if you use something like lilo to boot. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: The advantage of modules?
On Fri, Jan 05, 2001 at 10:50:20PM -0600, Evan Thompson wrote: I'd like to know (I know, I'm being slightly off topic, while still staying on topic, so I'm on topic...er...yes) if there is any advantage, be it memory-wise or architectuarally wise, to use modules? I already know the obvious points of if you are creating a distro that it is usually good to make a very modular kernel for those wishing not to recompile their kernel, but I was wondering if there were any other advantages to using modules vs. making a monolithic kernel for a kernel to be used only on one machine (with no other hardware support at all)? A couple of thoughts: 1) A full kernel with everything compiled in might not fit on boot media such as floppies, while modules allows you to not load stuff that isn't needed to until after the main booting is accomplished. 2) There are several devices that have multiple drivers (such as tulip, and old_tulip for example). Which particular driver works depends on your exact particular hardware. If both of these drivers are linked into the kernel, whatever the kernel chooses to initialize first will talk to the device. 3) Having drivers as modules means that you can remove them and reload them. When I was working in an office, I had one scsi controller that was a different brand (Adaptec) than the main scsi controller (TekRam), and I hung a disk in a removable chasis on the scsi chain in addition to a tape driver and cd-rom. When I was about to go home, I would copy all of the data to the disk, unmount it, and then unload the scsi device driver. I would take the disk out, and reload the scsi device driver to get the tape/cd-rom. I would then take the disk to my home computer. I would reverse the process when I came in the morning. 4) If you have multiple scsi controllers of different brands, building on into the kernel and the other brand(s) as modules allows you to control which scsi controller is the first controller in terms of where the disks are. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: The advantage of modules?
On Sat, Jan 06, 2001 at 11:02:15AM +0100, J . A . Magallon wrote: On 2001.01.06 Drew Bertola wrote: My best reasons are... Development: You don't have to recompile the kernel a billion times while working on a driver, you just recompile the module. Also, you can debug, unload, fix, recompile, reload a module to add or fix pieces of it all (hopefully) without rebooting. Practical usage: When I take my laptop on the road I use ppp, so I load it then. Most of the time I don't need it, so I don't load it. Usage: I have seen drivers which require params to work, and you can only give params if the driver is built as a module (ie, modprobe xx io=0x300 irq=5, etc...) because your hard is not properly autodetected by the module. For many devices you can specify the parameters at boot time if you use something like lilo to boot. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: The advantage of modules?
On Mon, Jan 08, 2001 at 07:26:01PM +0100, Ookhoi wrote: 3) Having drivers as modules means that you can remove them and reload them. When I was working in an office, I had one scsi controller that was a different brand (Adaptec) than the main scsi controller (TekRam), and I hung a disk in a removable chasis on the scsi chain in addition to a tape driver and cd-rom. When I was about to go home, I would copy all of the data to the disk, unmount it, and then unload the scsi device driver. I would take the disk out, and reload the scsi device driver to get the tape/cd-rom. I would then take the disk to my home computer. I would reverse the process when I came in the morning. You don't need modules for this to work. Quoting from drivers/scsi/scsi.c: /* * Usage: echo "scsi add-single-device 0 1 2 3" /proc/scsi/scsi * with "0 1 2 3" replaced by your "Host Channel Id Lun". * Consider this feature BETA. * CAUTION: This is not for hotplugging your peripherals. As * SCSI was not designed for this you could damage your * hardware ! * However perhaps it is legal to switch on an * already connected device. It is perhaps not * guaranteed this device doesn't corrupt an ongoing data transfer. */ so my take is unless you explicitly use hotplug devices (I wasn't), that it is much safer to unload the driver, unattach/attach scsi devices, and then reload the driver (which will scan the scsi bus for devices), which you need modules for. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
On Sat, Dec 16, 2000 at 02:52:42PM +0100, Andrea Arcangeli wrote: > On Sat, Dec 16, 2000 at 01:53:50PM +0600, Anuradha Ratnaweera wrote: > > GCC will complain the absence of a statement after `out1:out2:`, but not > > two complains for `out1' and `out2', because they form a single entity. > > I understand the formal specs (the email from Michael is very clear). What I'm > saying is that as the `dummy' statement is redoundant information but you're > requiring us to put it to build a labeled-statement, you could been even more > lazy and not define the labeled-statement as a statement so requiring us to put > a dummy statement after every label. That would been the same kind of issue > we're facing right now (but of course defining a labeled-statement as a > statement and allowing recursion makes the formal specs even simpler so that > probably wouldn't happen that easily). Basically, that's the way Dennis Ritchie decided it should be 26-27 years ago (C emerged between 1972 and 1973, according to the published history). It may be that C's ancestor languages (B and BCPL) had the same syntax, but since I've never used them, I can't say. Ultimately, all syntax is arbitrary, merely an agreement between language designers, implementers, standards committees and users. FWIW, it is rather low on my radar screen. If I had a magic Delorean and could go back in time to make some changes, I would: 1) Make all stdio functions consistant in taking the FILE * argument as the first argument. 2) Make && and || have the proper priority. 3) Make plain char and bitfields unsigned by default, add signed keyword to the original language. 4) Allow optional trailing ',' in enumeration lists. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
On Sat, Dec 16, 2000 at 02:52:42PM +0100, Andrea Arcangeli wrote: On Sat, Dec 16, 2000 at 01:53:50PM +0600, Anuradha Ratnaweera wrote: GCC will complain the absence of a statement after `out1:out2:`, but not two complains for `out1' and `out2', because they form a single entity. I understand the formal specs (the email from Michael is very clear). What I'm saying is that as the `dummy' statement is redoundant information but you're requiring us to put it to build a labeled-statement, you could been even more lazy and not define the labeled-statement as a statement so requiring us to put a dummy statement after every label. That would been the same kind of issue we're facing right now (but of course defining a labeled-statement as a statement and allowing recursion makes the formal specs even simpler so that probably wouldn't happen that easily). Basically, that's the way Dennis Ritchie decided it should be 26-27 years ago (C emerged between 1972 and 1973, according to the published history). It may be that C's ancestor languages (B and BCPL) had the same syntax, but since I've never used them, I can't say. Ultimately, all syntax is arbitrary, merely an agreement between language designers, implementers, standards committees and users. FWIW, it is rather low on my radar screen. If I had a magic Delorean and could go back in time to make some changes, I would: 1) Make all stdio functions consistant in taking the FILE * argument as the first argument. 2) Make and || have the proper priority. 3) Make plain char and bitfields unsigned by default, add signed keyword to the original language. 4) Allow optional trailing ',' in enumeration lists. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
On Fri, Dec 15, 2000 at 07:54:33PM +0100, Andrea Arcangeli wrote:
> On Fri, Dec 15, 2000 at 06:59:24PM +0100, Franz Sirl wrote:
> > It's required by ISO C, and since that's the standard now, gcc spits out a
> > warning. Just adding a ; is enough and already done for most stuff in
> > 2.4.0-test12.
>
> I'm not complaining gcc folks, I just dislike the new behaviour in general,
> it's inconsistent.
>
> This is wrong:
>
> x()
> {
>
> switch (1) {
> case 0:
> case 1:
> case 2:
> case 3:
> }
> }
>
> and this is right:
>
> x()
> {
>
> switch (1) {
> case 0:
> case 1:
> case 2:
> case 3:
> ;
> }
> }
>
> Why am I required to put a `;' only in the last case and not in all
> the previous ones? Or maybe gcc-latest is forgetting to complain about
> the previous ones ;)
Because neither
:(nor)
case :(nor)
default:
are statements by themselves. They are an optional start of a statement. The
ebnf looks like:
statement:
labeled-statement
| expression-statem
| compoundstatement
| selection-statement
| iteration-statement
| jump-statement
labeled-statement:
identifier ':' statement
| 'case' constant-expression ':' statement
| 'default' ':' statement
--
Michael Meissner, Red Hat, Inc. (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: [EMAIL PROTECTED] phone: +1 978-486-9304
Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
On Fri, Dec 15, 2000 at 04:06:36PM -0300, Horst von Brand wrote:
> "Richard B. Johnson" <[EMAIL PROTECTED]> said:
>
> [...]
>
> > Both examples allow an extern declaration inside a function scope
> > which is also contrary to any (even old) 'C' standards. 'extern'
> > is always file scope, there's no way to make it otherwise.
>
> AFAIR (rather dimly... no K at hand here) if you have an extern
> declaration inside a block, it will be visible only within that block. The
> object itself certainly is file scope (or larger).
Old K allowed the following:
foo(){
extern int a;
a = 1;
}
bar(){
a = 2;
}
Ie, compiler put the definition for a in the file scope symbol table, and not
the current block's. The above example is illegal in ISO C.
--
Michael Meissner, Red Hat, Inc. (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: [EMAIL PROTECTED] phone: +1 978-486-9304
Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
On Fri, Dec 15, 2000 at 04:06:36PM -0300, Horst von Brand wrote:
"Richard B. Johnson" [EMAIL PROTECTED] said:
[...]
Both examples allow an extern declaration inside a function scope
which is also contrary to any (even old) 'C' standards. 'extern'
is always file scope, there's no way to make it otherwise.
AFAIR (rather dimly... no KR at hand here) if you have an extern
declaration inside a block, it will be visible only within that block. The
object itself certainly is file scope (or larger).
Old KR allowed the following:
foo(){
extern int a;
a = 1;
}
bar(){
a = 2;
}
Ie, compiler put the definition for a in the file scope symbol table, and not
the current block's. The above example is illegal in ISO C.
--
Michael Meissner, Red Hat, Inc. (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: [EMAIL PROTECTED] phone: +1 978-486-9304
Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
On Fri, Dec 15, 2000 at 07:54:33PM +0100, Andrea Arcangeli wrote:
On Fri, Dec 15, 2000 at 06:59:24PM +0100, Franz Sirl wrote:
It's required by ISO C, and since that's the standard now, gcc spits out a
warning. Just adding a ; is enough and already done for most stuff in
2.4.0-test12.
I'm not complaining gcc folks, I just dislike the new behaviour in general,
it's inconsistent.
This is wrong:
x()
{
switch (1) {
case 0:
case 1:
case 2:
case 3:
}
}
and this is right:
x()
{
switch (1) {
case 0:
case 1:
case 2:
case 3:
;
}
}
Why am I required to put a `;' only in the last case and not in all
the previous ones? Or maybe gcc-latest is forgetting to complain about
the previous ones ;)
Because neither
label:(nor)
case expr:(nor)
default:
are statements by themselves. They are an optional start of a statement. The
ebnf looks like:
statement:
labeled-statement
| expression-statem
| compoundstatement
| selection-statement
| iteration-statement
| jump-statement
labeled-statement:
identifier ':' statement
| 'case' constant-expression ':' statement
| 'default' ':' statement
--
Michael Meissner, Red Hat, Inc. (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: [EMAIL PROTECTED] phone: +1 978-486-9304
Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] removal of "static foo = 0"
On Tue, Nov 28, 2000 at 04:16:12PM +0100, Andrea Arcangeli wrote: > On Tue, Nov 28, 2000 at 10:55:06AM +0100, Andreas Schwab wrote: > > Alexander Viro <[EMAIL PROTECTED]> writes: > > > > |> On Tue, 28 Nov 2000, Andrea Arcangeli wrote: > > |> > > |> > On Tue, Nov 28, 2000 at 12:10:33PM +0900, [EMAIL PROTECTED] wrote: > > |> > > If you have two files: > > |> > > test1.c: > > |> > > int a,b,c; > > |> > > > > |> > > test2.c: > > |> > > int a,c; > > |> > > > > |> > > Which is _stronger_? > > |> > > > |> > Those won't link together as they aren't declared static. > > |> > > |> Try it. They _will_ link together. > > > > Not if you compile with -fno-common, which should actually be the default > > some day, IMHO. > > I thought -fno-common was the default behaviour indeed, and I agree it should > become the default since current behaviour can lead to sublte bugs. (better I > discovered this gcc "extension" this way than after some day of debugging :) > > I'm all for gcc extensions when they're powerful and useful, but this > one looks absolutely worthless. I don't see any advantage from the current > behaviour (avoid an "extern" in some include file that we have/want to write > anyways to write correct C code?), and at least in large project (like the > kernel) where different part of the project are handled by different people > using -fno-common is pretty much mandatory IMHO. Umm, the original Ritchie C compiler on the PDP-11 and the Johnson 'Portable' C compiler both had this extension, as well as every other C compiler under UNIX (tm) I've ever used or read the documentation for. It is also mentioned in the standards as a common extension (I wrote the initial draft for this section in the C89 standard). When asked why the disconnect between what K said (ref/def model) and what their compilers actually did (common model), the AT representative at the time said that the ref/def model was put into K when they tried to make a C compiler for their IBM mainframes, using the standard linker, and discovered that linker would page align each common variable (CSECT in IBM terminology IIRC). The IBM linker is also the reason why the K and the C89 standard had the rule that global names must be unique to 6 characters, one case (which is another extension that just about everybody has and depends on). The default for C++ is -fno-common. -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] removal of static foo = 0
On Tue, Nov 28, 2000 at 04:16:12PM +0100, Andrea Arcangeli wrote: On Tue, Nov 28, 2000 at 10:55:06AM +0100, Andreas Schwab wrote: Alexander Viro [EMAIL PROTECTED] writes: | On Tue, 28 Nov 2000, Andrea Arcangeli wrote: | | On Tue, Nov 28, 2000 at 12:10:33PM +0900, [EMAIL PROTECTED] wrote: | If you have two files: | test1.c: | int a,b,c; | | test2.c: | int a,c; | | Which is _stronger_? | | Those won't link together as they aren't declared static. | | Try it. They _will_ link together. Not if you compile with -fno-common, which should actually be the default some day, IMHO. I thought -fno-common was the default behaviour indeed, and I agree it should become the default since current behaviour can lead to sublte bugs. (better I discovered this gcc "extension" this way than after some day of debugging :) I'm all for gcc extensions when they're powerful and useful, but this one looks absolutely worthless. I don't see any advantage from the current behaviour (avoid an "extern" in some include file that we have/want to write anyways to write correct C code?), and at least in large project (like the kernel) where different part of the project are handled by different people using -fno-common is pretty much mandatory IMHO. Umm, the original Ritchie C compiler on the PDP-11 and the Johnson 'Portable' C compiler both had this extension, as well as every other C compiler under UNIX (tm) I've ever used or read the documentation for. It is also mentioned in the standards as a common extension (I wrote the initial draft for this section in the C89 standard). When asked why the disconnect between what KR said (ref/def model) and what their compilers actually did (common model), the ATT representative at the time said that the ref/def model was put into KR when they tried to make a C compiler for their IBM mainframes, using the standard linker, and discovered that linker would page align each common variable (CSECT in IBM terminology IIRC). The IBM linker is also the reason why the KR and the C89 standard had the rule that global names must be unique to 6 characters, one case (which is another extension that just about everybody has and depends on). The default for C++ is -fno-common. -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] removal of "static foo = 0"
On Mon, Nov 27, 2000 at 10:35:45PM -0500, Alexander Viro wrote: > > > On Tue, 28 Nov 2000, Andrea Arcangeli wrote: > > > On Tue, Nov 28, 2000 at 12:10:33PM +0900, [EMAIL PROTECTED] wrote: > > > If you have two files: > > > test1.c: > > > int a,b,c; > > > > > > test2.c: > > > int a,c; > > > > > > Which is _stronger_? > > > > Those won't link together as they aren't declared static. > > Try it. They _will_ link together. This is a GCC extension (actually it is a pretty common UNIX extension, but the official standard says you can only have one definition of a global variable). Off the top of my head, here are some reasons variables could be put in different orders: 1) The compilation system has the concept of a small data pointer, which is a register that is assumed by the compiler to point to a small region of memory (it is never allocated by the compiler and setup in the initialization modules). The compiler decides to put some variables into the small data region and other variables outside of it. Typically the choice is based on size of the variable. Small data pointers are typically used when the machine has plenty of registers and it takes 2 or more instructions to build the address of a random variable in memory with load high/load low type instructions, and the small data pointer has the upper half already loaded, and uses special relocations to access the variable based off of the difference of a special symbol. 2) Even without a small data pointer, a compiler might decide to sort the variables emitted based on either size or number of accesses to take advantage of instructions with smaller offsets. 3) The above mentioned global, non-initialized variables (ie, the so-called 'common' variables). Where the linker puts the variables into the bss section in any order it chooses. For example, the VMS linker used to sort common variables alphabetically. 4) For static variables, the compilation system might decide to omit the variable until it sees a reference to the variable, and if the first variable is referenced in one function, and the second is referenced several functions later. 5) At some point in the future, on machines with many more registers than the normal 32, the linker might see all references to a variable, and decide to put it in a static register rather than memory. 6) A checkout compiler could randomly order things specifically to catch these type of errors (the problem with the normal checkout compilers that I'm aware of, is that the kernel uses structs to talk to real devices and interact with system calls with fixed layouts). -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] removal of "static foo = 0"
On Mon, Nov 27, 2000 at 09:41:39AM +0100, Werner Almesberger wrote: > Adam J. Richter wrote: > > At the moment, I have started daydreaming about instead > > writing an "elf squeezer" to do this and other space optimizations > > by modifying objdump. > > Hmm, this would require that gcc never calculates the location of an > explicitly initialized static variable based on the address of another > one. E.g. in > > static int a = 0, b = 0, c = 0, d = 0; > > ... > ... a+b+c+d ... > ... > > egcs-2.91.66 indeed doesn't seem to make this optimization on i386. > (Maybe the pointer increment or pointer offset solution would > actually be slower - didn't check.) But I'm not sure if this is also > true for other versions/architectures, or other code constructs. Jeff Law played with a similar optimization about 1-2 years ago, and eventually deleted all of the code because there were problems with the code. It would help some of our platforms (but not the x86) to access all variables in the same section via a common pointer. This is because on those systems, it often times takes 2-3 instructions to access global/static variables. Global variables you have more problems visiblity and such. -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] removal of "static foo = 0"
On Mon, Nov 27, 2000 at 06:21:13PM +0100, Andrea Arcangeli wrote:
> On Mon, Nov 27, 2000 at 12:39:55AM -0800, David S. Miller wrote:
> > Also I believe linkers are allowed to arbitrarily reorder members in
> > the data and bss sections. I could be wrong on this one though.
>
> I'm not sure either, but we certainly rely on that behaviour somewhere.
> Just to make an example fs/dquot.c:
>
> int nr_dquots, nr_free_dquots;
>
> kernel/sysctl.c:
>
> {FS_NRDQUOT, "dquot-nr", _dquots, 2*sizeof(int),
>
> The above is ok also on mips in practice though.
That needs to be fixed ASAP to use an array (not a structure). It is simply
wrong to depend on two variables winding up in at adjacent offsets.
--
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: [EMAIL PROTECTED] phone: +1 978-486-9304
Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] removal of static foo = 0
On Mon, Nov 27, 2000 at 09:41:39AM +0100, Werner Almesberger wrote: Adam J. Richter wrote: At the moment, I have started daydreaming about instead writing an "elf squeezer" to do this and other space optimizations by modifying objdump. Hmm, this would require that gcc never calculates the location of an explicitly initialized static variable based on the address of another one. E.g. in static int a = 0, b = 0, c = 0, d = 0; ... ... a+b+c+d ... ... egcs-2.91.66 indeed doesn't seem to make this optimization on i386. (Maybe the pointer increment or pointer offset solution would actually be slower - didn't check.) But I'm not sure if this is also true for other versions/architectures, or other code constructs. Jeff Law played with a similar optimization about 1-2 years ago, and eventually deleted all of the code because there were problems with the code. It would help some of our platforms (but not the x86) to access all variables in the same section via a common pointer. This is because on those systems, it often times takes 2-3 instructions to access global/static variables. Global variables you have more problems visiblity and such. -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] removal of static foo = 0
On Mon, Nov 27, 2000 at 10:35:45PM -0500, Alexander Viro wrote: On Tue, 28 Nov 2000, Andrea Arcangeli wrote: On Tue, Nov 28, 2000 at 12:10:33PM +0900, [EMAIL PROTECTED] wrote: If you have two files: test1.c: int a,b,c; test2.c: int a,c; Which is _stronger_? Those won't link together as they aren't declared static. Try it. They _will_ link together. This is a GCC extension (actually it is a pretty common UNIX extension, but the official standard says you can only have one definition of a global variable). Off the top of my head, here are some reasons variables could be put in different orders: 1) The compilation system has the concept of a small data pointer, which is a register that is assumed by the compiler to point to a small region of memory (it is never allocated by the compiler and setup in the initialization modules). The compiler decides to put some variables into the small data region and other variables outside of it. Typically the choice is based on size of the variable. Small data pointers are typically used when the machine has plenty of registers and it takes 2 or more instructions to build the address of a random variable in memory with load high/load low type instructions, and the small data pointer has the upper half already loaded, and uses special relocations to access the variable based off of the difference of a special symbol. 2) Even without a small data pointer, a compiler might decide to sort the variables emitted based on either size or number of accesses to take advantage of instructions with smaller offsets. 3) The above mentioned global, non-initialized variables (ie, the so-called 'common' variables). Where the linker puts the variables into the bss section in any order it chooses. For example, the VMS linker used to sort common variables alphabetically. 4) For static variables, the compilation system might decide to omit the variable until it sees a reference to the variable, and if the first variable is referenced in one function, and the second is referenced several functions later. 5) At some point in the future, on machines with many more registers than the normal 32, the linker might see all references to a variable, and decide to put it in a static register rather than memory. 6) A checkout compiler could randomly order things specifically to catch these type of errors (the problem with the normal checkout compilers that I'm aware of, is that the kernel uses structs to talk to real devices and interact with system calls with fixed layouts). -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] removal of static foo = 0
On Mon, Nov 27, 2000 at 06:21:13PM +0100, Andrea Arcangeli wrote:
On Mon, Nov 27, 2000 at 12:39:55AM -0800, David S. Miller wrote:
Also I believe linkers are allowed to arbitrarily reorder members in
the data and bss sections. I could be wrong on this one though.
I'm not sure either, but we certainly rely on that behaviour somewhere.
Just to make an example fs/dquot.c:
int nr_dquots, nr_free_dquots;
kernel/sysctl.c:
{FS_NRDQUOT, "dquot-nr", nr_dquots, 2*sizeof(int),
The above is ok also on mips in practice though.
That needs to be fixed ASAP to use an array (not a structure). It is simply
wrong to depend on two variables winding up in at adjacent offsets.
--
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: [EMAIL PROTECTED] phone: +1 978-486-9304
Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Universal debug macros.
On Sun, Nov 26, 2000 at 08:25:38PM -0800, H. Peter Anvin wrote: > Followup to: <[EMAIL PROTECTED]> > By author:Elmer Joandi <[EMAIL PROTECTED]> > In newsgroup: linux.dev.kernel > > > > Red Hat will ship two kernels. Well, they actually ship now about 4 ones > > or something. So they will ship 8. > > > > Something RedHat & co may want to consider doing is providing a basic > kernel and have, as part of the install procedure or later, an > automatic recompile and install kernel procedure. It could be > automated very easily, and on all but the very slowest of machines, it > really doesn't take that long. (Note, I work in the GCC group, not the Linux group, so the following is MHO, and not Red Hat gospel). Assuming you've installed the compiler/other relevant tools, installed the kernel source, and have enough disk space to build the kernel. This would screw people wanting to install Linux on their old 386/486/pentium for use as a firewall or web server. For example, the machine I'm planning on moving a web server to only has 2 gig of disk. Right now, I have barely enough space to hold the compiler tools plus web pages I want to serve. If I was serving much more content, I would probably chuck the compiler tools/kernel source. -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] removal of "static foo = 0"
On Sat, Nov 25, 2000 at 11:55:11PM +, Tim Waugh wrote: > On Sat, Nov 25, 2000 at 10:53:00PM +, James A Sutherland wrote: > > > Which is silly. The variable is explicitly defined to be zero > > anyway, whether you put this in your code or not. > > Why doesn't the compiler just leave out explicit zeros from the > 'initial data' segment then? Seems like it ought to be tought to.. Because sometimes it matters. For example, in kernel mode (and certainly for embedded programs that I'm more familiar with), the kernel does go through and zero out the so called BSS segment, so that normally uninitialized static variables will follow the rules as laid out under the C standards (both C89 and C99). I can imagine however, that the code that is executed before the BSS area is zeroed out needs to be extra careful in terms of statics that it references, and those must be hand initialized. -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] removal of static foo = 0
On Sat, Nov 25, 2000 at 11:55:11PM +, Tim Waugh wrote: On Sat, Nov 25, 2000 at 10:53:00PM +, James A Sutherland wrote: Which is silly. The variable is explicitly defined to be zero anyway, whether you put this in your code or not. Why doesn't the compiler just leave out explicit zeros from the 'initial data' segment then? Seems like it ought to be tought to.. Because sometimes it matters. For example, in kernel mode (and certainly for embedded programs that I'm more familiar with), the kernel does go through and zero out the so called BSS segment, so that normally uninitialized static variables will follow the rules as laid out under the C standards (both C89 and C99). I can imagine however, that the code that is executed before the BSS area is zeroed out needs to be extra careful in terms of statics that it references, and those must be hand initialized. -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Universal debug macros.
On Sun, Nov 26, 2000 at 08:25:38PM -0800, H. Peter Anvin wrote: Followup to: [EMAIL PROTECTED] By author:Elmer Joandi [EMAIL PROTECTED] In newsgroup: linux.dev.kernel Red Hat will ship two kernels. Well, they actually ship now about 4 ones or something. So they will ship 8. Something RedHat co may want to consider doing is providing a basic kernel and have, as part of the install procedure or later, an automatic recompile and install kernel procedure. It could be automated very easily, and on all but the very slowest of machines, it really doesn't take that long. (Note, I work in the GCC group, not the Linux group, so the following is MHO, and not Red Hat gospel). Assuming you've installed the compiler/other relevant tools, installed the kernel source, and have enough disk space to build the kernel. This would screw people wanting to install Linux on their old 386/486/pentium for use as a firewall or web server. For example, the machine I'm planning on moving a web server to only has 2 gig of disk. Right now, I have barely enough space to hold the compiler tools plus web pages I want to serve. If I was serving much more content, I would probably chuck the compiler tools/kernel source. -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Advanced Linux Kernel/Enterprise Linux Kernel
On Tue, Nov 14, 2000 at 11:41:33AM -0500, Richard B. Johnson wrote: > On Tue, 14 Nov 2000, Michael Rothwell wrote: > > > "Richard B. Johnson" wrote: > > > Multics??? [..] way too many persons on this list who know the history of > > > Unix to try this BS. > > > > So, you're saying their nine goals were bullshit? Multics had a lot of > > problems. But it did a lot of ground-breaking. Perhaps you should reply > > to the nine goals, or the general topic of "Enterpriseness," rather than > > merely express your irrelevant hatred for Multics. > > > > Relating some "nine goals of 'Enterprise Computing'" to Multics is > the bullshit. When Multics was being developed, the singular goal > was to make an operating system that worked on DEC Equipment without > having to use DEC software. The emphasis was on trying to make it > work period. Ummm, the way I parse the above statement, you are saying that Multics was developed to work on DEC equipment without having to use DEC software. Maybe we are inhabiting parallel universes, but I'm pretty sure that in my universe, Multics ran first on GE computers, and then on Honeywell computers when Honeywell bought the division from GE. Note, DEC did bid for the Multics contract but was turned down. Maybe you are thinking of Tenex or UNIX? The original machine was a GE-645, which was a segmented, virtual memory system using 36 bit words. The operating system and system software was written in PL/1. Bell Labs had bought a GE-645 and was one of the three development partners (along with GE and MIT) until they withdrew in April 1969. You might want to browse: http://www.multicians.org/ for more of the history of Multics. -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Advanced Linux Kernel/Enterprise Linux Kernel
On Tue, Nov 14, 2000 at 11:41:33AM -0500, Richard B. Johnson wrote: On Tue, 14 Nov 2000, Michael Rothwell wrote: "Richard B. Johnson" wrote: Multics??? [..] way too many persons on this list who know the history of Unix to try this BS. So, you're saying their nine goals were bullshit? Multics had a lot of problems. But it did a lot of ground-breaking. Perhaps you should reply to the nine goals, or the general topic of "Enterpriseness," rather than merely express your irrelevant hatred for Multics. Relating some "nine goals of 'Enterprise Computing'" to Multics is the bullshit. When Multics was being developed, the singular goal was to make an operating system that worked on DEC Equipment without having to use DEC software. The emphasis was on trying to make it work period. Ummm, the way I parse the above statement, you are saying that Multics was developed to work on DEC equipment without having to use DEC software. Maybe we are inhabiting parallel universes, but I'm pretty sure that in my universe, Multics ran first on GE computers, and then on Honeywell computers when Honeywell bought the division from GE. Note, DEC did bid for the Multics contract but was turned down. Maybe you are thinking of Tenex or UNIX? The original machine was a GE-645, which was a segmented, virtual memory system using 36 bit words. The operating system and system software was written in PL/1. Bell Labs had bought a GE-645 and was one of the three development partners (along with GE and MIT) until they withdrew in April 1969. You might want to browse: http://www.multicians.org/ for more of the history of Multics. -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Where is it written?
On Sat, Nov 11, 2000 at 12:28:54PM +1100, Keith Owens wrote: > On 10 Nov 2000 17:10:00 -0800, > "H. Peter Anvin" <[EMAIL PROTECTED]> wrote: > >We can mess with the ABI, but it requires a wholescale rev of the > >entire system. > > AFAICT, there is nothing stopping us from redoing the kernel ABI to > pass the first few parameters between kernel functions in registers. > As long as the syscall interface is unchanged, that ABI change will > only break binary modules (care_factor == 0). The ABI type would need > to be added to the symbol version prefix, trivial. Other than the minor little fact that -mregparm=n exposes several latent compiler bugs, that since it is not part of the ABI, it isn't on anybody's radar screen as needing to be fixed. This is of course the downside of free software, that volunteers tend to have their own ideas of what to work on. Also note, that for -mregpar=n, it is important that variable argument functions be declared properly in all callers, since they need to use the standard calling sequence. -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Where is it written?
On Fri, Nov 10, 2000 at 07:11:37PM -0500, Albert D. Cahalan wrote: > Michael Meissner writes: > > > It may be out of print by now, but the original reference > > for the x86 ABI, is the: > > > > System V Application Binary Interface > > Intel386 (tm) Processor Supplement > > > > When Cygnus purchased the manual I have, many moons ago, > > it was published by AT, with a copyright date of 1991, > > Gee that looks old. Might there be better calling conventions > for the Pentium 4 or Athlon? Memory latency, vector registers, > and more direct access to floating-point registers may mean > we ought to change the calling conventions. One would start > with the kernel of course, because it stands alone. Generally with ABIs you don't want to mess with it (otherwise you can't be guaranteed that a library built by somebody else will be compatible with your code, without all sorts of bits in the e_flags field). It allows multiple compilers to be provided that all interoperate (as long as they follow the same spec). Don't get me wrong -- in my 25 years of compiler hacking, I've never seen an ABI that I was completely happy with, including ABI's that I designed myself. ABIs by their nature are a compromise. That particular ABI was short sighted in that it wants only 32-bit alignment for doubles, instead of 64-bit alignment for instance, and also doesn't align the stack to higher alignment boundaries. -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Where is it written?
On Fri, Nov 10, 2000 at 08:37:56AM -0800, George Anzinger wrote: > I thought this would be simple, but... > > Could someone point me at the info on calling conventions to be used > with > x86 processors. I need this to write asm code correctly and I suspect > that it is a bit more formal than the various comments I have found in > the sources. Is it, perhaps an Intel doc? Or a gcc thing? It may be out of print by now, but the original reference for the x86 ABI, is the: System V Application Binary Interface Intel386 (tm) Processor Supplement When Cygnus purchased the manual I have, many moons ago, it was published by AT, with a copyright date of 1991, published by Prentice Hall, with an ISBN number of 0-13-877689-X. It most recently was published by SCO (possibly even Caldera, which just bought SCO). You can get an online version from: http://www.sco.com/developer/devspecs/abi386-4.pdf -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Where is it written?
On Fri, Nov 10, 2000 at 08:37:56AM -0800, George Anzinger wrote: I thought this would be simple, but... Could someone point me at the info on calling conventions to be used with x86 processors. I need this to write asm code correctly and I suspect that it is a bit more formal than the various comments I have found in the sources. Is it, perhaps an Intel doc? Or a gcc thing? It may be out of print by now, but the original reference for the x86 ABI, is the: System V Application Binary Interface Intel386 (tm) Processor Supplement When Cygnus purchased the manual I have, many moons ago, it was published by ATT, with a copyright date of 1991, published by Prentice Hall, with an ISBN number of 0-13-877689-X. It most recently was published by SCO (possibly even Caldera, which just bought SCO). You can get an online version from: http://www.sco.com/developer/devspecs/abi386-4.pdf -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Where is it written?
On Fri, Nov 10, 2000 at 07:11:37PM -0500, Albert D. Cahalan wrote: Michael Meissner writes: It may be out of print by now, but the original reference for the x86 ABI, is the: System V Application Binary Interface Intel386 (tm) Processor Supplement When Cygnus purchased the manual I have, many moons ago, it was published by ATT, with a copyright date of 1991, Gee that looks old. Might there be better calling conventions for the Pentium 4 or Athlon? Memory latency, vector registers, and more direct access to floating-point registers may mean we ought to change the calling conventions. One would start with the kernel of course, because it stands alone. Generally with ABIs you don't want to mess with it (otherwise you can't be guaranteed that a library built by somebody else will be compatible with your code, without all sorts of bits in the e_flags field). It allows multiple compilers to be provided that all interoperate (as long as they follow the same spec). Don't get me wrong -- in my 25 years of compiler hacking, I've never seen an ABI that I was completely happy with, including ABI's that I designed myself. ABIs by their nature are a compromise. That particular ABI was short sighted in that it wants only 32-bit alignment for doubles, instead of 64-bit alignment for instance, and also doesn't align the stack to higher alignment boundaries. -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Where is it written?
On Sat, Nov 11, 2000 at 12:28:54PM +1100, Keith Owens wrote: On 10 Nov 2000 17:10:00 -0800, "H. Peter Anvin" [EMAIL PROTECTED] wrote: We can mess with the ABI, but it requires a wholescale rev of the entire system. AFAICT, there is nothing stopping us from redoing the kernel ABI to pass the first few parameters between kernel functions in registers. As long as the syscall interface is unchanged, that ABI change will only break binary modules (care_factor == 0). The ABI type would need to be added to the symbol version prefix, trivial. Other than the minor little fact that -mregparm=n exposes several latent compiler bugs, that since it is not part of the ABI, it isn't on anybody's radar screen as needing to be fixed. This is of course the downside of free software, that volunteers tend to have their own ideas of what to work on. Also note, that for -mregpar=n, it is important that variable argument functions be declared properly in all callers, since they need to use the standard calling sequence. -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: xterm: no available ptys
On Mon, Nov 06, 2000 at 12:37:38PM -0800, Paul Powell wrote: > Hello, > > I have created a trimmed down /dev directory to be > used with my custom bootable Linux CD. I've run into > a problem where I can't start an xterm. I get the > error... > > xterm: no available ptys > > I'm not sure which device I'm missing in /dev. I'm no > expert on how the tty's and stuff work so feel free to > fill me in. Everything else seems to work fine on the > CD. Did you mount /dev/pts, which is usually done with a line in /etc/fstab: none /dev/pts devpts gid=5,mode=0622 0 0 -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: xterm: no available ptys
On Mon, Nov 06, 2000 at 12:37:38PM -0800, Paul Powell wrote: Hello, I have created a trimmed down /dev directory to be used with my custom bootable Linux CD. I've run into a problem where I can't start an xterm. I get the error... xterm: no available ptys I'm not sure which device I'm missing in /dev. I'm no expert on how the tty's and stuff work so feel free to fill me in. Everything else seems to work fine on the CD. Did you mount /dev/pts, which is usually done with a line in /etc/fstab: none /dev/pts devpts gid=5,mode=0622 0 0 -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)
On Sat, Nov 04, 2000 at 02:24:00PM +0200, Kai Henningsen wrote: > [EMAIL PROTECTED] (Andi Kleen) wrote on 02.11.00 in ><[EMAIL PROTECTED]>: > > > again with a different syntax than gcc [I guess it would have been too easy > > to just use the gcc syntax] > > One of the big problems in C99 was that there was nobody on the committee > who really understood gcc well, so the committee had problems using gcc > solutions given that nobody would be able to really describe them. Or the GCC syntax was too limited to do all of what the committee wanted. > And the reason no such expert was there was that the FSF didn't send > anyone, because they seem to think standards tend to ignore what they want > to do. Actually, RMS had quite a lot of influence on the original standard, even though he didn't attend the meetings. His replies to the public comment period were fairly long and real insightful. Even if some of his issues were voted down, they were discussed over quite a few meetings. I was on the original ANSI C committee from its founding, through the C89 standard, and for a year or two afterwards as the initial changes for C99 were discussed, for a total of 10 1/2 years (representing first Data General, then for OSF, though the early Data General years were before I switched over to GCC). Towards the end, I was rather burned out by the process, and didn't push too hard at Cygnus to go to the meetings, and nobody seemed willing to step in (at the time Cygnus only had 4 GCC engineers, and like now there was always more GCC work to do than bodies to do work). The trouble is it takes a lot of time from your paying job to actively participate (figure 4 week long meetings a year, plus the time to read documents, wordsmith, etc.). -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)
On Fri, Nov 03, 2000 at 10:19:12PM -0800, Russ Allbery wrote: > Tim Riker <[EMAIL PROTECTED]> writes: > > > Agreed. C99 does not replace all the needed gcc features. We should > > start using the ones that make sense, and push for > > standardization/documentation on the rest. > > > I'm perfectly happy with this as a long term goal. I'll put what effort > > I can into moving that direction without breaking the existing world as > > we know it. > > May I tentatively suggest that one point at which your resources could > productively be applied is towards improving the C99 compliance in gcc? > Clearly for the near to medium future the compiler that everyone will use > to build the Linux kernel will be gcc, which means that in order to use > any C99 syntax, it first has to be solid in gcc. That means the best way > of introducing such things into the Linux kernel is to *first* get the C99 > support solid, reliable, and efficient in gcc, then once a version of gcc > is released with that support, help get Linux compiling with that version > of gcc. > > *Then*, when that version of gcc can be made a prerequisite for the > kernel, you can start switching constructs over to the C99 syntax that gcc > supports. Hm. Last month the compiler related thread on the kernel list was the kernel couldn't move to newer versions of the compiler because the compiler had changed things (where newer might mean either the latest snapshot de jour, or a tested/appropriately patched version based off of the snapshots, or even 2.95). Now people seem to be advocating moving the kernel to use features from C99 that haven't even been coded yet (which mean when coded using the latest codegen as well). Note, I seriously doubt Linus will want a flag day (ie, after a given kernel release, you must use revision n of the compiler, but before that release, you must use revision n-1 of the compiler), so you still have to maintain support for the old GCC way of doing things, in addition to the C99 way of doing things probably for a year or so. -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)
On Fri, Nov 03, 2000 at 10:19:12PM -0800, Russ Allbery wrote: Tim Riker [EMAIL PROTECTED] writes: Agreed. C99 does not replace all the needed gcc features. We should start using the ones that make sense, and push for standardization/documentation on the rest. I'm perfectly happy with this as a long term goal. I'll put what effort I can into moving that direction without breaking the existing world as we know it. May I tentatively suggest that one point at which your resources could productively be applied is towards improving the C99 compliance in gcc? Clearly for the near to medium future the compiler that everyone will use to build the Linux kernel will be gcc, which means that in order to use any C99 syntax, it first has to be solid in gcc. That means the best way of introducing such things into the Linux kernel is to *first* get the C99 support solid, reliable, and efficient in gcc, then once a version of gcc is released with that support, help get Linux compiling with that version of gcc. *Then*, when that version of gcc can be made a prerequisite for the kernel, you can start switching constructs over to the C99 syntax that gcc supports. Hm. Last month the compiler related thread on the kernel list was the kernel couldn't move to newer versions of the compiler because the compiler had changed things (where newer might mean either the latest snapshot de jour, or a tested/appropriately patched version based off of the snapshots, or even 2.95). Now people seem to be advocating moving the kernel to use features from C99 that haven't even been coded yet (which mean when coded using the latest codegen as well). Note, I seriously doubt Linus will want a flag day (ie, after a given kernel release, you must use revision n of the compiler, but before that release, you must use revision n-1 of the compiler), so you still have to maintain support for the old GCC way of doing things, in addition to the C99 way of doing things probably for a year or so. -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)
On Sat, Nov 04, 2000 at 02:24:00PM +0200, Kai Henningsen wrote: [EMAIL PROTECTED] (Andi Kleen) wrote on 02.11.00 in [EMAIL PROTECTED]: again with a different syntax than gcc [I guess it would have been too easy to just use the gcc syntax] One of the big problems in C99 was that there was nobody on the committee who really understood gcc well, so the committee had problems using gcc solutions given that nobody would be able to really describe them. Or the GCC syntax was too limited to do all of what the committee wanted. And the reason no such expert was there was that the FSF didn't send anyone, because they seem to think standards tend to ignore what they want to do. Actually, RMS had quite a lot of influence on the original standard, even though he didn't attend the meetings. His replies to the public comment period were fairly long and real insightful. Even if some of his issues were voted down, they were discussed over quite a few meetings. I was on the original ANSI C committee from its founding, through the C89 standard, and for a year or two afterwards as the initial changes for C99 were discussed, for a total of 10 1/2 years (representing first Data General, then for OSF, though the early Data General years were before I switched over to GCC). Towards the end, I was rather burned out by the process, and didn't push too hard at Cygnus to go to the meetings, and nobody seemed willing to step in (at the time Cygnus only had 4 GCC engineers, and like now there was always more GCC work to do than bodies to do work). The trouble is it takes a lot of time from your paying job to actively participate (figure 4 week long meetings a year, plus the time to read documents, wordsmith, etc.). -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 2.2.17 with RedHat 7 Problem !
On Mon, Oct 23, 2000 at 07:48:08PM -0400, David Relson wrote: > Horst, > > What you say is correct. Early comments on gcc-2.96 reflected preprocessor > changes which made it impossible to compile a kernel. Later comments, > particularly David Wragg's "struct itimerval" example, show that compiler > optimizations is broken. > > My recollection is that the behavior of "a[i] = b[i++]" is well defined, > i.e. in the standard. However it's been years since I paid attention to > those details, so I may be wrong. Umm, no, since a[i] = b[i++] does not have a sequence, it is explicitly undefined behavior in the standard. As I recall Bernd Schmidt recently found a number of places where the above construct is used in the Linux kernel. -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 2.2.17 with RedHat 7 Problem !
On Mon, Oct 23, 2000 at 07:48:08PM -0400, David Relson wrote: Horst, What you say is correct. Early comments on gcc-2.96 reflected preprocessor changes which made it impossible to compile a kernel. Later comments, particularly David Wragg's "struct itimerval" example, show that compiler optimizations is broken. My recollection is that the behavior of "a[i] = b[i++]" is well defined, i.e. in the standard. However it's been years since I paid attention to those details, so I may be wrong. Umm, no, since a[i] = b[i++] does not have a sequence, it is explicitly undefined behavior in the standard. As I recall Bernd Schmidt recently found a number of places where the above construct is used in the Linux kernel. -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 2.2.17 with RedHat 7 Problem !
On Sun, Oct 22, 2000 at 11:16:36PM -0400, David Relson wrote:
> At 09:14 PM 10/22/00, Horst von Brand wrote:
> >Jurgen Kramer <[EMAIL PROTECTED]> said:
> >
> > > You can blame it on the compiler which is included with RH7.0. It's a
> > > pre-release version of some sort. It seems that the gcc people are not
> > > happy that RH included this version with RH7.
> >
> >It is the *kernel's* fault, as far as can be ascertained now. The compiler
> >is stricter, and implements new optimizations, for which the kernel (being
> >only ever compiled with gcc) is just unprepared.
>
> The problem, as I understand it, is that gcc-2.96 handles language
> constructs slightly different than older compilers. This is a preprocessor
> change, not an optimization problem.
>
> To say "new optimizations ... kernel ... unprepared" is incorrect. Having
> worked with compilers (some years ago), I always took it as an article of
> faith that the same answer(s) would be generated whether optimization was
> turned on or not. Optimization should always be a way to do a task either
> quicker (fewer instructions executing, less executing time, etc) or shorter
> (less memory needed for the instructions). Optimization should never,
> never give a different result. Having new optimizations break an executing
> program is simply wrong.
Ummm, that should read "Having new optimizations break a correct exeucting
program...". For example, the following program:
#include
int main(){
int i;
printf ("i = %d\n", i);
return 0;
}
will necessarily print different values for i, depending on the optimization
level, what was on the stack and in the registers when main started, and
possibly other criteria. Just because a program is executing, it doesn't mean
it is correct.
Both the kernel and the compiler are large complex pieces of software, and
almost certainly have bugs in them, and over the years, I have certainly found
some of these bugs as I use new versions of each.
--
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: [EMAIL PROTECTED] phone: +1 978-486-9304
Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 2.2.17 with RedHat 7 Problem !
On Sun, Oct 22, 2000 at 11:16:36PM -0400, David Relson wrote:
At 09:14 PM 10/22/00, Horst von Brand wrote:
Jurgen Kramer [EMAIL PROTECTED] said:
You can blame it on the compiler which is included with RH7.0. It's a
pre-release version of some sort. It seems that the gcc people are not
happy that RH included this version with RH7.
It is the *kernel's* fault, as far as can be ascertained now. The compiler
is stricter, and implements new optimizations, for which the kernel (being
only ever compiled with gcc) is just unprepared.
The problem, as I understand it, is that gcc-2.96 handles language
constructs slightly different than older compilers. This is a preprocessor
change, not an optimization problem.
To say "new optimizations ... kernel ... unprepared" is incorrect. Having
worked with compilers (some years ago), I always took it as an article of
faith that the same answer(s) would be generated whether optimization was
turned on or not. Optimization should always be a way to do a task either
quicker (fewer instructions executing, less executing time, etc) or shorter
(less memory needed for the instructions). Optimization should never,
never give a different result. Having new optimizations break an executing
program is simply wrong.
Ummm, that should read "Having new optimizations break a correct exeucting
program...". For example, the following program:
#include stdio.h
int main(){
int i;
printf ("i = %d\n", i);
return 0;
}
will necessarily print different values for i, depending on the optimization
level, what was on the stack and in the registers when main started, and
possibly other criteria. Just because a program is executing, it doesn't mean
it is correct.
Both the kernel and the compiler are large complex pieces of software, and
almost certainly have bugs in them, and over the years, I have certainly found
some of these bugs as I use new versions of each.
--
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: [EMAIL PROTECTED] phone: +1 978-486-9304
Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9 + Winchip2/2A processor family == hang on boot
On Wed, Oct 11, 2000 at 02:26:08PM +0100, [EMAIL PROTECTED] wrote: > I actually thought that the i686 target was the same as the i586 target > with different instruction scheduling rules. Seems my judgement was off. > /me goes to read gcc docs i686 has conditional integer move and conditional floating point move, and a few other instructions that GCC currently does not generate code for such as atomic exchange of 8 bytes. -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9 + Winchip2/2A processor family == hang on boot
On Wed, Oct 11, 2000 at 02:26:08PM +0100, [EMAIL PROTECTED] wrote: I actually thought that the i686 target was the same as the i586 target with different instruction scheduling rules. Seems my judgement was off. /me goes to read gcc docs i686 has conditional integer move and conditional floating point move, and a few other instructions that GCC currently does not generate code for such as atomic exchange of 8 bytes. -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Large File support and blocks.
On Fri, Sep 01, 2000 at 12:01:39PM -0700, Matthew Jacob wrote: > > > > Or use --print-libgcc-file-name: > > > > `gcc --print-libgcc-file-name` > > > > where are the options normally used to compile code (ie, for example > > on machines that optionally do not have a floating point use, adding > > -msoft-float would select the libgcc.a that was compiled with -msoft-float). > > Tsk. Showing my age and ignorance, I guess. I was using the gcc -v trick back > at Auspex in '93. ...Guess the compiler driver has gotten smarter since. > You know how it goes- you do a trick once- you don't change it for years... According to the ChangeLog of the 2.7.2.3 compiler, Doug Evans added it in March of 1995. -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Large File support and blocks.
On Fri, Sep 01, 2000 at 10:34:19AM -0700, Matthew Jacob wrote: > > On Fri, Sep 01, 2000 at 03:15:27PM +0200, Andi Kleen wrote: > > > So what do you propose to use when a long long division is needed (after > > > much thought and considering all alternatives etc.etc.) ? > > > > Link against libgcc, what else? > > As also does anyone who does solaris drivers (x86 or sparc) using gcc- the > code that gcc emits that requires 64 bit operations is quite nicely available > in libgcc.a. Only a minor bit of hackage with gcc -v is needed in a makefile > to emit the correct path for the linker to use. Or use --print-libgcc-file-name: `gcc --print-libgcc-file-name` where are the options normally used to compile code (ie, for example on machines that optionally do not have a floating point use, adding -msoft-float would select the libgcc.a that was compiled with -msoft-float). > That is, unless somebody wants to write the support functions (specific to > gcc, ah, but which one?) into the linux kernel? Oh dear, I don't think so.. Other than division, most of the 64 bit support functions are fairly easy to write. Obviously, if you do this and gcc 7.0 changes the interface to call different functions, you are hosed. -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Large File support and blocks.
On Fri, Sep 01, 2000 at 10:34:19AM -0700, Matthew Jacob wrote: On Fri, Sep 01, 2000 at 03:15:27PM +0200, Andi Kleen wrote: So what do you propose to use when a long long division is needed (after much thought and considering all alternatives etc.etc.) ? Link against libgcc, what else? As also does anyone who does solaris drivers (x86 or sparc) using gcc- the code that gcc emits that requires 64 bit operations is quite nicely available in libgcc.a. Only a minor bit of hackage with gcc -v is needed in a makefile to emit the correct path for the linker to use. Or use --print-libgcc-file-name: `gcc options --print-libgcc-file-name` where options are the options normally used to compile code (ie, for example on machines that optionally do not have a floating point use, adding -msoft-float would select the libgcc.a that was compiled with -msoft-float). That is, unless somebody wants to write the support functions (specific to gcc, ah, but which one?) into the linux kernel? Oh dear, I don't think so.. Other than division, most of the 64 bit support functions are fairly easy to write. Obviously, if you do this and gcc 7.0 changes the interface to call different functions, you are hosed. -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Large File support and blocks.
On Fri, Sep 01, 2000 at 12:01:39PM -0700, Matthew Jacob wrote: Or use --print-libgcc-file-name: `gcc options --print-libgcc-file-name` where options are the options normally used to compile code (ie, for example on machines that optionally do not have a floating point use, adding -msoft-float would select the libgcc.a that was compiled with -msoft-float). Tsk. Showing my age and ignorance, I guess. I was using the gcc -v trick back at Auspex in '93. ...Guess the compiler driver has gotten smarter since. You know how it goes- you do a trick once- you don't change it for years... According to the ChangeLog of the 2.7.2.3 compiler, Doug Evans added it in March of 1995. -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
