Re: Referring what kernel-images to build to the technical committee?
[EMAIL PROTECTED] (Herbert Xu) writes: kernel where all options were compiled into separate modules so simply choosing the right modules constructs the optimal kernel. Guess what, that's how the current 2.4 kernel images are constructed. Well, not really. All of the drivers and other pieces which can be delivered as modules, perhaps... but you're still having to deliver N different kernel-image packages to handle options that are *not* modular, which is the root of this whole discussion. If we step back from the details for a moment, it could be argued that the presence of so many compile-time-only options in the ia32 support is a kernel design fault. However, which options are configurable at compile time only and which are configurable at run time in the Linux kernel is beyond Debian's control. Personally, the combination of a single precompiled binary kernel package for ia32 and an improved toolset for assisting users with the process of configuring and compiling a kernel that is truly optimized for their situation seems like a better approach than lots of prebuilt kernels... Bdale
Re: Referring what kernel-images to build to the technical committee?
Herbert == Herbert Xu [EMAIL PROTECTED] writes: Herbert Steve Greenland [EMAIL PROTECTED] wrote: Confusion: Adding 8 (or whatever it is) variations of each kernel version is going to make it harder to select the appropriate one. There is some fraction of the target audience who won't know what kind of CPU they have, and we don't want to have to add to the Debian installation instructions: Now open your computer's case, and locate the large chip with fans hanging off of it. Write down the numbers and letters on top of the chip. Now look them up in this table to determine the best kernel for your machine. Herbert There is a file called /proc/cpuinfo you know. Thats fine if you have already booted Linux. However, if you are reading the installation instructions (as what Steve was saying), then you probably do not have a Linux system yet. Whats the point of finding out what the correct kernel is only after you have downloaded it? -- Brian May [EMAIL PROTECTED]
Re: Referring what kernel-images to build to the technical committee?
On Thu, Apr 26, 2001 at 09:19:56AM -0700, David Schleef wrote: It could also be useful as a hardware tester at install time: Would you like to test your hardware (and get a kernel custom build for your hardware at the same time)? This process will potentially take a long time. (Yes, I realize this idea is a bit crazier than average.) Who'll write all the stuff to test for said hardware, no-name variants, etc, etc, ad nauseum? -- Daniel Stone [EMAIL PROTECTED]
Re: Referring what kernel-images to build to the technical committee?
Brian May [EMAIL PROTECTED] wrote:
Thats fine if you have already booted Linux. However, if you are
reading the installation instructions (as what Steve was saying), then
you probably do not have a Linux system yet.
Whats the point of finding out what the correct kernel is only after
you have downloaded it?
You're missing the point. These kernels are only available after
installation. They're not used on boot floppies.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Referring what kernel-images to build to the technical committee?
David Schleef [EMAIL PROTECTED] wrote: On Thursday 26 April 2001 09:05, Andreas Metzler wrote: _Afair_ it is necessary to run a k6 (or athlon) optimized kernel to use 3DNow! in applications like xmms or lame. This probably applys to ISSE, MTTR and MMX, too. This is not correct. [snip] Hello! Thanks for clearing this up, apparently my memory tricked me. Sorry for the distraction. cu andreas -- I am happy I added these two underscores to afair ;-)
Re: Referring what kernel-images to build to the technical committee?
On Fri, Apr 27, 2001 at 08:00:49PM +1000, Daniel Stone wrote: On Thu, Apr 26, 2001 at 09:19:56AM -0700, David Schleef wrote: It could also be useful as a hardware tester at install time: Would you like to test your hardware (and get a kernel custom build for your hardware at the same time)? This process will potentially take a long time. (Yes, I realize this idea is a bit crazier than average.) Who'll write all the stuff to test for said hardware, no-name variants, etc, etc, ad nauseum? There's a great tester at ftp://ftp.kernel.org/pub/linux/kernel/v2.4 dave...
Re: Referring what kernel-images to build to the technical committee?
In fact, most of the options could be auto-detected from /proc/cpuinfo. It could also be useful as a hardware tester at install time: Would you like to test your hardware (and get a kernel custom build for your hardware at the same time)? This process will potentially take a long time. (Yes, I realize this idea is a bit crazier than average.) Even if your idea sounds a little bit crazy, this is probably the best way at the moment to get a well suited kernel. But I'd rather see a kernel where all options were compiled into separate modules so simply choosing the right modules constructs the optimal kernel. This could be done during an install or setup process. Sound crazy? Maybe now but how about in the future? O. Wyss -- Please CC.
Re: Referring what kernel-images to build to the technical committee?
Otto Wyss [EMAIL PROTECTED] wrote:
Even if your idea sounds a little bit crazy, this is probably the best
way at the moment to get a well suited kernel. But I'd rather see a
kernel where all options were compiled into separate modules so simply
choosing the right modules constructs the optimal kernel. This could be
Guess what, that's how the current 2.4 kernel images are constructed.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Referring what kernel-images to build to the technical committee?
Sam Hartman [EMAIL PROTECTED] wrote: [...] Summary: Herbert has started building 8 different flavors of kernel-image for i386. These flavors correspond to CPU type; for example there is an appropriate kernel for people with 386 machines to run and an appropriate kernel for people with Athlon machines to run. [...] I'd like to summarize my understanding of the tradeoffs that we have identified in the debian-devel discussion so that if we do turn this issue over to the committee, they will know what concerns we have already identified. Please add to the following list if I have missed something. [...] performance: By having images optimized for each processor on i386 users should see better performance. I don't believe performance numbers were quantified in the discussion but quantifying performance is probably important to evaluating this tradeoff. [...] Hello! _Afair_ it is necessary to run a k6 (or athlon) optimized kernel to use 3DNow! in applications like xmms or lame. This probably applys to ISSE, MTTR and MMX, too. Please correct me if I am wrong. tia, cu andreas -- Uptime: 10 seconds load average: 0.00, 0.00, 0.00 vim:ls=2:stl=***\ Sing\ a\ song.\ ***
Re: Referring what kernel-images to build to the technical committee?
On Thu, Apr 26, 2001 at 12:58:10PM +1000, Craig Sanders wrote:
On Wed, Apr 25, 2001 at 08:30:31PM -0400, Sam Hartman wrote:
[...]
i think you've done a good job of summarising the issues.
I agree as well.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Referring what kernel-images to build to the technical committee?
On Thursday 26 April 2001 09:05, Andreas Metzler wrote: performance: By having images optimized for each processor on i386 users should see better performance. I don't believe performance numbers were quantified in the discussion but quantifying performance is probably important to evaluating this tradeoff. [...] Hello! _Afair_ it is necessary to run a k6 (or athlon) optimized kernel to use 3DNow! in applications like xmms or lame. This probably applys to ISSE, MTTR and MMX, too. I agree that having kernels compiled with support for different features is a good idea. We must provide an i386 kernel. There is software available which only runs with MMX. We should offer a kernel with MMX support which requires Pentium-MMX to support running this. For 3DNow! we should have a kernel which supports it. There is no need for a MTTR specific kernel. MTTR is not really needed as there is no software written which is unable to run without it. Our goal here should be compatibility with software. MTTR can increase speed significantly in certain situations, but there's lots of other ways of doing that for less effort which we aren't supporting. MTTR can allow you to work around broken hardware. But we can't provide enough kernels to support all combinations of broken hardware (I am sure that I could find a list of a dozen boolean options which are all needed to be in one state or another for various broken hardware - we can't provide 2^12 kernels). Also I think that we should have an SMP kernel in the list. Another issue is support for all the different SCSI controllers and RAID controllers. Perhaps we should spend more time working on initrd support? -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
Re: Referring what kernel-images to build to the technical committee?
RC There is no need for a MTTR specific kernel. MTTR is not really RC needed as there is no software written which is unable to run RC without it. Our goal here should be compatibility with software. RC MTTR can increase speed significantly in certain situations, but RC there's lots of other ways of doing that for less effort which we RC aren't supporting. MTTR can allow you to work around broken RC hardware. But we can't provide enough kernels to support all RC combinations of broken hardware (I am sure that I could find a RC list of a dozen boolean options which are all needed to be in one RC state or another for various broken hardware - we can't provide RC 2^12 kernels). I think you are wrong about 'MTTR is not really needed'. One good example is aviplay (player for avi files). It perfomance is seriously affected by MTTR option. This fact is mentioned in its docs and I've seen myself *significant* difference in its perfomance when I've compiled kernel with MTTR option. Probably perfomance of simular programs will be affected too. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Ilya Martynov (http://martynov.org/)| | GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 | | AGAVA Software Company (http://www.agava.com/) | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Re: Referring what kernel-images to build to the technical committee?
On Thursday 26 April 2001 16:38, Ilya Martynov wrote: RC There is no need for a MTTR specific kernel. MTTR is not really RC needed as there is no software written which is unable to run RC without it. Our goal here should be compatibility with software. RC MTTR can increase speed significantly in certain situations, but RC there's lots of other ways of doing that for less effort which we RC aren't supporting. MTTR can allow you to work around broken RC hardware. But we can't provide enough kernels to support all RC combinations of broken hardware (I am sure that I could find a RC list of a dozen boolean options which are all needed to be in one RC state or another for various broken hardware - we can't provide RC 2^12 kernels). I think you are wrong about 'MTTR is not really needed'. One good example is aviplay (player for avi files). It perfomance is seriously affected by MTTR option. This fact is mentioned in its docs and I've seen myself *significant* difference in its perfomance when I've compiled kernel with MTTR option. Probably perfomance of simular programs will be affected too. I've played many AVI files without MTRR support. It will still work, just a bit slower. If programs won't run at all (as in the case of MMX and 3DNow!) then we should compile different kernels. If they just don't run as fast then we can let the users compile their own kernels. If you want maximum video speed you want to compile your own kernel with AGP and DRI support etc... -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
Re: Referring what kernel-images to build to the technical committee?
RC I've played many AVI files without MTRR support. It will still RC work, just a bit slower. I think it depends on configuration. On my home PC aviplay is almost unusable without MTRR. It looks like slide show instead movie. aviplay docs mention that some people reported up to x3 increase in perfomance. I've not seen such perfomance increase myself but it is really significant. With MTRR it is *possible* for me to watch movies. RC If programs won't run at all (as in the case of MMX and 3DNow!) RC then we should compile different kernels. If they just don't run RC as fast then we can let the users compile their own kernels. I understand your point. I just want you to understand that MTRR support in kernel can be more important than you think. Nowdays Linux is much less hackers project. There is a lot of people who don't need to know how recompile kernel. Many of them want to watch movies. Many of them will wonder 'Why Linux is so slow?'. RC If you want maximum video speed you want to compile your own RC kernel with AGP and DRI support etc... AFAIK both AGP and DRI can be compiled as modules so they should be compiled anyway in stock kernel. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Ilya Martynov (http://martynov.org/)| | GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 | | AGAVA Software Company (http://www.agava.com/) | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Re: Referring what kernel-images to build to the technical committee?
On 04/26/2001 09:59:13 AM Russell Coker wrote: On Thursday 26 April 2001 16:38, Ilya Martynov wrote: RC There is no need for a MTTR specific kernel. MTTR is not really RC needed as there is no software written which is unable to run RC without it. Our goal here should be compatibility with software. RC MTTR can increase speed significantly in certain situations, but RC there's lots of other ways of doing that for less effort which we RC aren't supporting. MTTR can allow you to work around broken RC hardware. But we can't provide enough kernels to support all RC combinations of broken hardware (I am sure that I could find a RC list of a dozen boolean options which are all needed to be in one RC state or another for various broken hardware - we can't provide RC 2^12 kernels). I think you are wrong about 'MTTR is not really needed'. One good example is aviplay (player for avi files). It perfomance is seriously affected by MTTR option. This fact is mentioned in its docs and I've seen myself *significant* difference in its perfomance when I've compiled kernel with MTTR option. Probably perfomance of simular programs will be affected too. I've played many AVI files without MTRR support. It will still work, just a bit slower. If programs won't run at all (as in the case of MMX and 3DNow!) then we should compile different kernels. If they just don't run as fast then we can let the users compile their own kernels. If you want maximum video speed you want to compile your own kernel with AGP and DRI support etc... Naw, lets just quadruple the number of kernels we have so we can have: 1) kernel without AGP or DRI 2) kernel with AGP and no DRI 3) kernel without AGP with DRI 4) kernel with AGP and with DRI For each of the 30 or so processor revisions that can be compiled for. After all, if half a dozen kernels for the i386 port of debian is OK instead of 1, what's wrong with quadrupling it again? The same arguements apply to that case. Eventually there will be so many kernels that newbies will find it quicker and easier to navigate make xconfig that to navigate dselect. And optimizations aren't just limited to playing AVIs. I recall a few years ago a special version of mpg123 that was optimized for a 486. A 486-33 that could barely play a mono 22.1 K mpeg easily played stereo 44.2 K mpegs with the optimizations, if I recall correctly. We desparately need to include that of course. I'm sure similar optimizations could be added to mpg123 that would reduce processor load on a P4-1ghz by 0.001 % so we need to include that of course. If we are going to recompile everything to get 1% better performance, we should have the guts to split the i386 port into all the little processor families instead of this halfway stuff.
Re: Referring what kernel-images to build to the technical committee?
On Thu, Apr 26, 2001 at 04:15:15PM +0200, Russell Coker wrote: On Thursday 26 April 2001 09:05, Andreas Metzler wrote: _Afair_ it is necessary to run a k6 (or athlon) optimized kernel to use 3DNow! in applications like xmms or lame. This probably applys to ISSE, MTTR and MMX, too. This is not correct. There is software available which only runs with MMX. We should offer a kernel with MMX support which requires Pentium-MMX to support running this. For 3DNow! we should have a kernel which supports it. All kernels, even if compiled with CONFIG_M386, will support MMX and 3DNow. It just won't use memcpy_mmx() or memcpy_3d() as the implementation of memcpy(). The important part is saving the correct number of FP registers, which is done. There is no need for a MTTR specific kernel. Right. You compile kernels with CONFIG_MTRR=y, and the kernel will detect if the processor supports it at run-time. (I am sure that I could find a list of a dozen boolean options which are all needed to be in one state or another for various broken hardware - we can't provide 2^12 kernels). If you were to report this as a kernel bug, it would probably be fixed quickly. i386 CONFIG_ dependencies are designed reasonably enough that you can expect to build one kernel that runs on most hardware (apart from non-arch driver issues.) Also I think that we should have an SMP kernel in the list. We could have one kernel with CONFIG_SMP=y. It doesn't conflict with other things, although this is an option that is likely to be on your list above. CONFIG_M386 is one as well, since the kernel can't use the better locking primitives that appeared in the 486. I'd like to see a single binary kernel (or two, because I'm suspicious about CONFIG_M386), and an easy system that allows you to build one of a set of standard kernels, i.e., a kernel that has everything enabled as modules, but varies in optimized processor, SMP, high memory support, etc. In particular, I don't think it's appropriate (in the idea I'm describing) to present the user with questions such as Do you want APM support? -- compile it in or as a module, and figure it out at run-time. In fact, most of the options could be auto-detected from /proc/cpuinfo. It could also be useful as a hardware tester at install time: Would you like to test your hardware (and get a kernel custom build for your hardware at the same time)? This process will potentially take a long time. (Yes, I realize this idea is a bit crazier than average.) dave...
Re: Referring what kernel-images to build to the technical committee?
Good summary, Sam. I'd like to add a couple extra points: On 25-Apr-01, 19:30 (CDT), Sam Hartman [EMAIL PROTECTED] wrote: Should build custom: Some argumed that users should build a custom kernel and the distribution was doing them a disservice by trying to provide kernels that met their needs. There was also a slightly different argument: That *if* the user needs the slight performance improvement offered by a CPU optimized kernel, then *probably* that user is both capable of building his/her own, *and* would gain further (and possibly more significant) performance benefits by many other choices one could make when configuring a kernel (module vs. non-module, etc.) Confusion: Adding 8 (or whatever it is) variations of each kernel version is going to make it harder to select the appropriate one. There is some fraction of the target audience who won't know what kind of CPU they have, and we don't want to have to add to the Debian installation instructions: Now open your computer's case, and locate the large chip with fans hanging off of it. Write down the numbers and letters on top of the chip. Now look them up in this table to determine the best kernel for your machine. How larget that fraction is I don't know, but I'd wager it was larger than 0. Archive Size: CD Size: Bandwith: Module Multiplication, size, bandwidth: Someone (sorry, forget who) proposed that instead of actually distributing a lot of different stock kernels, we distribute some sort kernel-tuner package that included the various config files and made it easy for a user to build a custom kernel that matched the Debian stock kernel except for CPU specificity (and one could extend this to a matrix of CPU/AGP/DRI choices). Perhaps it could present a menu of choices (pick the things you have) and then select (or generate) the appropriate config file, use make-kpkg to build the new kernel, and then install the new kernel.deb. Yes, it would take longer, but it doesn't have any of the negative impacts on the archive, and it starts the user on the path to custom kernel competency. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Referring what kernel-images to build to the technical committee?
On Thursday 26 April 2001 18:19, David Schleef wrote: For 3DNow! we should have a kernel which supports it. All kernels, even if compiled with CONFIG_M386, will support MMX and 3DNow. It just won't use memcpy_mmx() or memcpy_3d() as the implementation of memcpy(). The important part is saving the correct number of FP registers, which is done. There is no need for a MTTR specific kernel. Right. You compile kernels with CONFIG_MTRR=y, and the kernel will detect if the processor supports it at run-time. So a 386 compiled kernel can still support MMX, 3DNow! and MTRR? In that case we only need a 386 kernel, but it might be nice to have a PentiumMMX compiled kernel as well (that should give better performance on all brands of CPU that are better than 486). (I am sure that I could find a list of a dozen boolean options which are all needed to be in one state or another for various broken hardware - we can't provide 2^12 kernels). If you were to report this as a kernel bug, it would probably be fixed quickly. i386 CONFIG_ dependencies are designed reasonably enough that you can expect to build one kernel that runs on most hardware (apart from non-arch driver issues.) I am thinking of the various IDE options for dealing with broken drives and controllers, PCI Quirks, etc. These things will break some machines when set one way and break other machines on the other setting. I'd like to see a single binary kernel (or two, because I'm suspicious about CONFIG_M386), and an easy system that allows you to build one of a set of standard kernels, i.e., a kernel that has everything enabled as modules, but varies in optimized processor, SMP, high memory support, etc. In particular, I don't think it's appropriate (in the idea I'm describing) to present the user with questions such as Do you want APM support? -- compile it in or as a module, and figure it out at run-time. In fact, most of the options could be auto-detected from /proc/cpuinfo. So we ship half the kernel as binary and compile the other half after installation? Sounds terrible. Why not just compile custom kernels for every user? It wouldn't be that difficult to write a script that asks a dozen easy questions, checks the /proc data, and then compiles an optimised kernel. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
Re: Referring what kernel-images to build to the technical committee?
On Thu, Apr 26, 2001 at 10:13:01PM +0200, Russell Coker wrote: So a 386 compiled kernel can still support MMX, 3DNow! and MTRR? In that case we only need a 386 kernel, but it might be nice to have a PentiumMMX compiled kernel as well (that should give better performance on all brands of CPU that are better than 486). Except that the PentiumMMX kernel won't run on a Pentium -- it uses MMX instructions for memcpy(). (I now ramble into things I only slightly remember, so please check before believing...) I think the general consensus is that the original Pentium instruction ordering is best all-around, whereas PentiumPro is the worst. I am thinking of the various IDE options for dealing with broken drives and controllers, PCI Quirks, etc. These things will break some machines when set one way and break other machines on the other setting. I haven't heard of many problems like this recently. But I'm sure there will be such bugs during the lifetime of 2.4. So we ship half the kernel as binary and compile the other half after installation? Sounds terrible. Why not just compile custom kernels for every user? (Yes, that doesn sound terrible.) No, I meant to ship and install one standard complete kernel. If the user wants to run the automatic kernel optimisation script and compile a new kernel, cool. But the idea is to make it as simple as Do you want an optimized kernel? It wouldn't be that difficult to write a script that asks a dozen easy questions, checks the /proc data, and then compiles an optimised kernel. I tend to think that asking fewer questions is better -- a script will better know how to optimise the kernel for someone that is unprepared. And the people that want more configuration options should be compiling their own kernels anyway. dave...
Re: Referring what kernel-images to build to the technical committee?
Steve Greenland [EMAIL PROTECTED] wrote:
Confusion: Adding 8 (or whatever it is) variations of each kernel
version is going to make it harder to select the appropriate one. There
is some fraction of the target audience who won't know what kind of CPU
they have, and we don't want to have to add to the Debian installation
instructions:
Now open your computer's case, and locate the large chip with fans
hanging off of it. Write down the numbers and letters on top of the
chip. Now look them up in this table to determine the best kernel
for your machine.
There is a file called /proc/cpuinfo you know.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Referring what kernel-images to build to the technical committee?
Previously Herbert Xu wrote: There is a file called /proc/cpuinfo you know. And /proc/hardware on some architectures. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: Referring what kernel-images to build to the technical committee?
On Thu, Apr 26, 2001 at 04:59:13PM +0200, Russell Coker wrote: If programs won't run at all (as in the case of MMX and 3DNow!) then we should compile different kernels. If they just don't run as fast then we can let the users compile their own kernels. I don't understand why MMX or 3dnow apps can't be used if the kernel isn't compiled to support them. Only the K7 configuration adds 3dnow support, but 3dnow in mpg123 works (or at least seems to) on my k6-3 with k6 chosen for the cpu type in the kernel config. -- - -/- - Rahul Jain - -\- - - -\- http://linux.rice.edu/~rahul -=- mailto:[EMAIL PROTECTED] -/- - - -/- I never could get the hang of Thursdays. - HHGTTG by DNA -\- - |--||--||-|--|-|-|-| Version 11.423.999.220020101.23.50110101.042 (c)1996-2000, All rights reserved. Disclaimer available upon request.
Re: Referring what kernel-images to build to the technical committee?
On Wed, Apr 25, 2001 at 08:30:31PM -0400, Sam Hartman wrote: [...] i think you've done a good job of summarising the issues. i hope we can resolve this soon. craig -- craig sanders [EMAIL PROTECTED] GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
