Hello comments inline. regards, sandeep. -----Original Message----- From: anaconda-devel-list-bounces@xxxxxxxxxx [mailto:anaconda-devel-list-bounces@xxxxxxxxxx] On Behalf Of John Summerfield Sent: Tuesday, March 25, 2008 1:48 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: 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. <sandeep> We already push the updates upstream either directly or through our partners. Some of our customers prefer to qualify an OS say rhel 5.0. Test that setup and leave it that way till thier next refresh cycle. the duration of which may not align with the redhat update cycle. > 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. <sandeep> 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. <sandeep> It is for those customers who dont like to update to a newer release every 6 months. Or for those customers who buy new hardware but use an older OS on it. Secondly the purpose of this patch is to automagically pull the kernel modules and drivers from the usb-storage media. These days usb-storage (flash media) is cheap and as such usb-storage media has good driver support, we dont do driver updates for usb-storage devices often? Thirdly dkms is our method of installing these drivers. your could have a source tarball, source rpm or a binary tarball and achieve the same thing, dkms is one of theways of achieving this. 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! >> <sandeep> This is not about free and non-free stuff, that is a differnet topic. This a method to solve a problem that customers have. >> >> > > -- 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 _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
