Autoconfiguration: Original design scenario

Hello.

There are a lot of noise about autoconfiguration. And the scenarios of ESR are not my original scenarios, for which I worked autoconfigurator for nearly 1.5 years.

A lot of people already compiles the kernel. (Why? Maybe ESR or other people haw sudied this, but I don't know the answer)
proof: using the facts:
- there are a lot of kernel.org mirrors.
- posting in the user lists

The people will ocmpile the kernel without the distribution's configuration, removing not needed drivers.
(I don't have a proof, but the people that use .config from distribution, normally use also the updated kernel source package in the distribution.)

Finding card -> configuration is not easy.
You buy a network card (ethernet), which is the correct driver? And the usb photo machine? The sound card? Some info are in configure.help, but you should parse 20/50 entries before maybe to find your card name.

I designed autoconfigure to help these people. So (at the beggining) a not complete detection, but used to help the people that ALREADY normally compile the kernel.

[ In Alan diary, I found that he tried some drivers before to find the driver for Telsa new tape. Autoconfigure will help also hackers.
Hmm. Was the card ISA? so forget the above example ]

So do you think autoconfigure can be usefull for people?

After adding a lot of detection and configuration in my database I found that in a modern machine, autoconfigure can build a complete and working configuration.

ESR read me autoconfiguration in this late stage, so he thinks about the 'single button' step for some aunts, students...

In summary: the autoconfigure is already usefull (IMHO) for a lot of people.

The other ESR scenarios are 'add-on' without extra working. They can be usefull, we can make it, but we should see if distributions/users like the 'one key configuration and building kernel'. Reading some *-users lists and doing some support in IRC, I think think people wuould like to use it.

Anyway these 'add-on' are nearly off-topic to lkml

giacomo

Not particularly wanting to add to the rediculously high level of noise on this list, but yes, that's happened to be once before, but for a PCI ISDN card.

There weren't many clues on the card packaging what it was, and couldn't find anything on the net about the card, so resourted to the "insmod this module, does it do anything" approach. After many hours of prodding around and reading source, turns out that it needed the hisax driver with various random parameters.

I really don't see why hisax couldn't say "oh, you have an ISDN card with IDs xxxx:xxxx, that's hisax type nn" and be done with it, rather than needing to be told "pci id xxxx:xxxx type nn". Have a look at drivers/isdn/hisax/config.c and wonder how the hell you take some random vendors PCI ISDN card and work out how to drive it under Linux.

(For the record, the card was:
1397:2bd0 - Cologne Chip Designs GmbH - HFC-PCI 2BD0 ISDN
and the driver requirements were: hisax type 35 proto 2)

Realistically, I don't think any autoconfigurator will solve such cases until these areas can be fixed up reasonably.

Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Autoconfigure cannnot solve this.
The card is not in my database.
To help user, you should tell the driver maintainer to add our card in the know pci devices. In this manner autoconfigure, hotplug and modutils can take easy use your card.

This is also a problem of PCI design.
ISAPNP have the function type, USB have also the function class, so that there exists few interfaces, and kernel can ask only to specific interface and not to the specific card. PCI also have the interface field, but not very used, and the interfaces are also not so standardized.

giacomo

The hisax driver already has a MODULE_DEVICE_TABLE entry for it's pci devices, and this data shows up in the modules.pcimap table in the modules directory.

Russell, when /sbin/hotplug is part of the initramfs in 2.5, the driver will automatically be loaded for your new card, IF you have all the different modules already built. You will not need autoconfigure, just a good vendor kernel :)

Giacomo, please, please, please, just use the info in the MODULE_DEVICE_TABLE entries for your autoconfigure program. Don't try to keep all of this data up to date by hand, just use the info that is already in the kernel. It is a battle you will always loose. Automate this process (David Brownell has made a proposal that will work for you), and you will never have to generate those PCI and USB tables by hand again.

One other autoconfigure problem that I don't think anyone has mentioned, USB devices that only show up when they want to transfer data to/from the host. Like all of the Palm based devices. They don't stay connected long enough for a "probe all the busses" tool like you are currently developing to detect.

thanks,

greg k-h

Greg KH <[email protected]>:

Giacomo will probably answer definitively, but I believe he is already generating all of the PCI, PNP, and module probes by script. We're planning to ship the probe table generator with a future CML2 version.

Which is why the "standalone" mode of the autoconfigurator turns all that stuff modular. The autoprobe doesn't, it's intended to generate a facilities report that can be used to tune by hand.

		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Never trust a man who praises compassion while pointing a gun at you.

Chuckle. I believe you still need to pass the module parameters, even though it can detect the chip. I have no idea why, and I no longer have the ISDN card within my administrative control.

Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Why not just have the probe table automatically generated against the current kernel? That way you don't have to release a new version of the autoconfigure program for _every_ kernel version (including the -pre versions.)

I feel like I'm sounding like a broken record here...

greg k-h

Greg KH <[email protected]>:

Mainly because there is a certain amount of hand-hacking involved in turning the raw output of the probe table generator into a usable probe table.

Giacomo is trying to cut down on this and may eliminate it altogether. If he doesn't, I'll take a swing at it myself.

		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Government is actually the worst failure of civilized man. There has
never been a really good one, and even those that are most tolerable
are arbitrary, cruel, grasping and unintelligent.	-- H. L. Mencken 

You should read better the mail of Russell.
Russel should give special parameter, because the card IS NOT in MODULES_DEVICE_TABLE.

We need good MODULES_DEVICE_TABLE. Autoconfigure and hotplug need correct and complete MODULED_DEVICE_TABLES.

(The card is 1397:2bd0)

IIRC I've already told you that I generated the list in a semi-automated way. But MODULE_DEVICE_TABLE is not complete. The ide controller use a different procedure.
Until enought drivers (IDE controller are important) will use the pci_device_id, I will maintain also other kind of pci detection. Unfortunatelly these are less accurate: sometime drivers check for PCI controller/moptherboard for workaround. And my tools don't know about 'right' cards and workorund driver detections.

This ia a problem.
In my design: I detect mouse and other important USB devices, and let user to select other devices.
In Eric design: the USB devices are automatically set to 'm' if we found a USB controller.

Yes, it is a problem. Thus we cannot make 'autoconfiguration in

one key touch/mouse click'
I will think more about this problem in next days.

giacomo

The fact that hisax needs command line parameters even for PCI cards only has historical reasons. In 2.5 this is scheduled to change, such that an insmod automatically will do the right thing. It will remain as-is in 2.4 for compatibility reasons.

--Kai