On Mar 17, 2008, at 6:21 AM, <Sandeep_K_Shandilya@xxxxxxxx> <Sandeep_K_Shandilya@xxxxxxxx
> wrote:
Hello
Qualified drivers for server hardware that are on on
support.dell.com are dkms rpms (http://linux.dell.com/projects.shtml#dkms
). The licensing is GPL.
The licensing of what is GPL? DKMS? I looked at dkms at one point
and viewed as something I don't really need. Correct me if I'm wrong,
but it's a shim that lets kernel modules be loaded on any version
(within reason) of the kernel. You're still distributing binary-only
drivers in that case. To me that's a major loss because I, as the
user, don't want to go to support.dell.com and hunt for drivers. I
just want the OS to provide them and not have to worry about it.
Also, I was unable to find any Linux drivers for server hardware on
support.dell.com.
-----Original Message-----
From: anaconda-devel-list-bounces@xxxxxxxxxx on behalf of John
Summerfield
Sent: Mon 3/17/2008 5:27 PM
To: Discussion of Development and Customization of the Red Hat Linux
Installer
Subject: Re: [ PATCH ] RFC: Search and load drivers automatically
from usb-storage media
Sandeep_K_Shandilya@xxxxxxxx wrote:
Hello All
I have moved this discussion from bugzilla to the mailing list
Currently customers have to use driver disks or usb-storage to
install
to newer
hardware (NICS and disk controllers) for which the OS does not have
support.
The customer has to manually prepare driver disks or give boot time
command line
options to locate these driver disk images.
This method could be improved.
Here are some of the questions Jeremy had with regard to this patch.
Please read inline <sandeep>
A few comments from a quick look:
1) Instead of posting patches in private bugs, it's far better to
send
them to
anaconda-devel-list so they can actually be looked at and commented
on
by the
community, not just some private Dell/Red Hat interaction, that is
what
I have done.
2) Automatic mounting of partitions with no way to opt-out can lead
to
problems
over time
<sandeep> Do you have any specific areas in the anaconda loader
that you
are referrring to?
we will anyway unmount the partition after copying the driver
updates to
ramfs.
3) The naming is terrible. What's OEM specific about this
functionality?
<Sandeep> Well, nothing OEM about it except the OEM's would like to
install the drivers that they have tested and qualified with NEW
hardware.
4) What's better about doing this automatically as opposed to
actually
having
the user specify that "yes, I have a driver disk"
<Sandeep> Think about it this way, Suppose the drivers with new
hardware
support are placed in a utility partition (OEM will prepare this on
the
system) on an embedded USB storage device, or thinking a little bit
more
into the future the driver may reside on the internet
Dell is already pursuing this and Dell servers to be released in
future
may have embedded usb-storage with drivers, diagnostics etc...
I'm a user. It sounds to me like we have a vendor's hear.
No hardware I use has a binary-only driver that I use. If the driver's
not open-source, I don't want it.
Sometimes I've found it necessary to use a driver that is open-source
(mostly)[1] but is no incorporated into the kernel as shipped by my
vendor - Red Hat/Fedora, SUSE/OpenSUSE, Debian, Ubuntu, and it's a
pain.
If you're a vendor supporting Linux I appreciate that, and if you do
it
properly I will tend to favour your products.
[1] I'll name names. The madwifi driver. I'm happy with how well it
works, I'm not entirely happy with the Very Crude Hack someone's
engineered to help users keep in step, and when I can find wireless
that
works less painfully than Atheros I will buy it.
I ignore the binary-only drivers from ATI and nvidia. I want to be
able
to choose when to install my primary vendor's updates, not wait for
someone else to catch up. Not even one day.
And if the Vendor's Dell hear this. Standard graphics on Dells sucks
bunnies through garden hoses. I'm taking about whether it works at
all,
not how swish it is, and I'm talking about on-board graphics.
I have to agree with John here. As a Linux user, one of the major
gains is not having to go to twenty different vendor sites to get tiny
little drivers just to make the system work. I hear Windows users
having to do this and I think it's a huge time waste.
The only legitimate case I can think of where users would want to
provide drivers during installation is in the case where they want to
install a very old Linux release on very new hardware (RHEL3 on my
quad core quadxeon quadsystem!), which seems to be common with EL
customers. That's fine, but I also have to agree with Bill in that
scanning all volumes for drivers is not a great idea. Works ok for
small servers, but when get much larger systems connected to much
larger storage devices, suddenly installation takes forever.
--
David Cantrell <dcantrell@xxxxxxxxxx>
Red Hat / Honolulu, HI
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
