Sandeep_K_Shandilya@xxxxxxxx wrote:
Hello John
comments inline.
regards,
sandeep.
-----Original Message-----
From: anaconda-devel-list-bounces@xxxxxxxxxx
[mailto:anaconda-devel-list-bounces@xxxxxxxxxx] On Behalf Of John
Summerfield
Sent: Monday, March 24, 2008 5:09 PM
To: Discussion of Development and Customization of the Red Hat Linux
Installer
Subject: Re: [ PATCH ] RFC: Search and load drivers automatically
fromusb-storage media
Sandeep_K_Shandilya@xxxxxxxx wrote:
Hello John
comments inline.
regards,
sandeep.
-----Original Message-----
From: anaconda-devel-list-bounces@xxxxxxxxxx
[mailto:anaconda-devel-list-bounces@xxxxxxxxxx] On Behalf Of John
Summerfield
Sent: Wednesday, March 19, 2008 5:24 AM
To: Discussion of Development and Customization of the Red Hat Linux
Installer
Subject: Re: [ PATCH ] RFC: Search and load drivers automatically
fromusb-storage media
Sandeep_K_Shandilya@xxxxxxxx wrote:
Hello John
That is what this patch is attempting to do, solve the problem of
hunting for drivers on the net. This patch is changing anaconda so
that it automagically looks for drivers in USB storage embedded
inside
the box loads and installs it. Maybe not for the old hardware that
you
already are using but for the upcoming servers.
So you have binary-only drivers?
<sandeep>
dkms rpms carry source and binaries. The binarie kernel modules could
be used at install time to recognise new hardware. Once install
completes then you could install the dkms rpms.
I have dkms installed on one of my servers, it was pulled in when I
installed madwifi, along with a heap of other stuff including gcc. I am
not enthused at having gcc installed on a server.
<sandeep>
Dell does not support or package the madwifi driver. we dont promote
this hardware on linux.
I don't think your interpretation of what I said is reasonable.
Here is a layout of the file system, This should make it a lot clear
now.
oemdrv/
oemdrv/megaraid_sas_dd.img
oemdrv/mptlinux_dd.img
oemdrv/abc/
oemdrv/abc/megaraid_sas_dkms.noarch.rpm
oemdrv/def/
oemdrv/def/dkms-2.0.17-1.noarch.rpm
oemdrv/hij/
oemdrv/hij/mptlinux-dkms.noarch.rpm
the *dd.img will be used at install time( this has to contain binary
kernel modules ).
The rpms contain the binaries and the source. The binaries are
compiled against the Dell supported RHEL distro. if you have a new
rhel distro the source will be installed by dkms in /usr/src/.. you
could compile the driver for your distro and use it.
infact dkms is also available in the universe section on ubuntu. dkms
is supported on many other linux distro's.
It is not clear to me that you have answered my question. When I use the
term "binary-only drivers," I mean drivers for which Dell does not
willingly provide source.
<sandeep> dkms is a packaging tool and anybody could use it as a vehicle
to publish open-source or non-opensource drivers. I am NOT saying that a
*dkms.rpm == opensource driver. I think you mistook me on that.
I didn't mistake you, I couldn't figure what you meant or whether you
were addressing the question.
Is there any part of the Dell drivers for which a customer cannot get
the source under an OSI-approved licence, preferably GPL2 or later?
< sandeep >
For Server hardware, drivers are opensource (all drivers ship with
source)
In that case, what prevents their inclusion in the kernel? Achieve that,
and there's no need for dkms, every time RH or CentOS or Debian builds a
new kernel, the matching driver is built to and there's no need to go
fishing them out of some obscure corner of the imbedded USB storage. And
providing source to clients becomes a problem for RH, CentOS, Debian
etc, and it's a problem they address very well indeed and their clients
understand how it's done.
a few client hardware drivers are non-opensource( Eg 3d acclerated
drivers and wireless drivers )
Ah yes, the things I needed for my GX-270.
I might want to run RHEL, I might prefer CentOS or even Fedora, all of
with Anaconda supports, or I might even prefer a distro which Anaconda
does not support such as Debian, and I may not care whether it's
_certified_ on my platform provided that there's a reasonable
probability that it will work and that my hardware vendor won't be too
harsh if there's a problem.
<sandeep>
This patch and RFC is specifically for anaconda.
I appreciate that, but the problem applies equally to _all_ distros
people might want to use.
Whether someone chooses to use RHEL, CentOS, Fedora, SLES, Debian,
Slackware or something else, if the drivers are open source and part of
the kernel, they can see it's certified for RHEL with the standard
drivers, insta;; whatever on it, and if it breaks, the RH, CentOS,
FedoraProject, Novell, Debian or Patrick has a fair chance of fixing it.
And the FreeBSD, NetBSD, OpenBSD and other BSD folk can all port the
drivers to their systems too.
_I_ do in fact run all the distros I've just mentioned, and more.
If Dell wants to be difficult about the source code to its drivers, and
any of other vendors such as Sun, HP and IBM does provide source and
help should I have problems with non-certified hardware, the Dell is
batting on a very sticky wicket.
<sandeep>
As I already mentioned, with respect to Server hardware (Poweredge
brand) you should have nothing to worry.
I am glad to hear that, but it leaves me puzzled as to why the drivers
might be stored in a USB storage device, and why DKMS is needed to load
them.
Firmware for (eg) wireless on client hardware maybe, it's a whole
different debate.
My very favourite rescue disk is Knoppix. Sometimes I have the latest
on hand, sometimes not. I am less concerned about security updates
than I am about my regular distro, so provided the CD to hand boots
I'm happy to use it. I use it for Linux and Windows systems alike - i
can't do a lot to _repair_ a broken Windows system, but it can help
with cloning it, with resizing its filesystems etc.
Debian is very picky about what it allows into its distro, and Knoppix
is based off Debian. Klaus Knopper, who created Knoppix, might not see
value in including DKMS, he has to make some sacrifices to get it all
down to a single CD.
If it doesn't work with your hardware, then I can't use my favourite
rescue CD.
If I'm running a standard RHEL or CentOS or Fedora or Debian or *SUSE
system and I have a problem, I have a well-defined path to follow to
report it and in the fullness of time to get a fix.
As I understand it, if I'm running one of your binary-only drivers, I
don't have any support. The kernel's tainted and, I've been told, the
fact of the driver's being loaded means it could have done bad things.
I recall an incident, many years ago, when RH was bitten by this very
issue, in respect of CDE that RH used to distribute with RHL. RH
couldn't fix CDE and its supplier wouldn't or wouldn't do it in the
timeframe RH required.
I'm not sure that DELL would provide full support for RHEL, or even
the kernel, on one of its servers.
And if you think I'm difficult, go to debian.org and read some of the
discussions about non-free bits in the kernel!
--
Cheers
John
-- spambait
1aaaaaaa@xxxxxxxxxxxxxxxx Z1aaaaaaa@xxxxxxxxxxxxxxxx
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375
You cannot reply off-list:-)
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
