[Lula] Linux Kernel Guru Needed

[John Mark Schofield]

Thanks very much for the reply, Peter.

On Fri, Feb 29, 2008 at 3:21 PM, Peter Benjamin <pete at peterbenjamin.com> wrote:

>  The first thing to do for new hardware is boot the latest
>  the Ubuntu from CD, and see what drivers it used.  Those
>  will be the right drivers in 98% of the cases.  And in 5%
>  they might need code changes to support the oddball aspects,
>  imho.  That is what I have read over the years.  And my
>  own experience with Ubuntu, and echoed by others in LULA.

We've found that to be largely true, with the exception being
brand-new hardware from manufacturers. (Sometimes we get stuff that's
still in beta; BIOSes that shout "Not for distribution" at boot, etc.)

We're using Ubuntu Dapper 6.06 -- the long-term-support version. We're
finding that even if a piece of hardware works perfectly in Gutsy or
Hardy, backporting the driver to Dapper can be a problem. We're
currently facing an issue where adding a module to support a new wired
NIC takes out the previously-working wifi card in that model. (Still
digging into that one; don't quote me if it turns out to be a
different cause.) {grin} But we have lots of issues like that -- we've
been trying to do all this with installable modules, so we don't have
to recompile the Ubuntu kernel, but we've passed the point where that
seems workable, and now we're compiling kernels too.

In the past, I've had problems getting new wifi cards to work with
WPA/WPA2 encryption, and we've in fact moved towards using ndiswrapper
as a wifi driver solution, because we've had so much trouble with
non-Intel wifi drivers. (The Intel ones rock!)

>  Once you know what drivers Ubuntu selected, then you can add
>  them to your stripped down version.  Why strip it down?  Just
>  add another 10 meg of RAM?  Is the app really that IO bound?
>  Point is, maintaining mods when upgrading the kernel or OS
>  is a lot of work, that may not have a positive ROI.  Just
>  because the last programmer did it, hardware is much improved,
>  and stripping down may no longer be necessary for ROI.
>  Benchmarking both would be telling.  And do so with each
>  release, and plot the curves into the future to compare
>  the cost programmer time (tens of hours for each release)
>  to ROI.  I'd consider it likely the margin of return has
>  already past, if running on a dual duo server mobo with
>  the best FSB speed.

Stripped down in the sense of "it's an appliance, so they don't need
most apps, so we don't install firefox or openoffice, etc." We're not
stripping it down that much -- we're not really doing embedded Linux;
our appliance (www.dakim.com) is a full-fledged touchscreen linux
computer with a gig of RAM.

(Oh yeah. Touchscreens have been a big pain in the past, in terms of
getting the hardware working.)

>  With regards to desktop and GUI... name some names, KDE or Gnome?
>  Or XWindows or ____?  There are just too many and you need to
>  post more specifics.

We're running a GTK-based app on the IceWM window manager. But this
thread isn't about getting help with a specific problem, it's about
pointers to general information, or someone interested in a paid gig
of brain-dumping kernel/driver/whatever info to me.

We're not doing driver development ourselves -- this is all about
integrating and making functional drivers and hardware that other
manufacturers provide to us.

I'm looking for tips, methods, tool suggestions, troubleshooting
ideas, etc. To buzzwordize it, I guess I'm looking for the "best
practices" around driver/kernel/module/etc. management and
installation in a Debian/Ubuntu environment.


--John


-- 
---------------------------------------------------
Got root? http://blog.sudosu.net