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.
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
