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
On Tue, Jan 15, 2002 at 11:17:49AM +0100, Giacomo Catenazzi wrote:
> [ 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
> ]
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
Russell King wrote:
> 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.
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
On Tue, Jan 15, 2002 at 01:41:57PM +0100, Giacomo Catenazzi wrote:
>
> Russell King wrote:
>
>
> >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.
>
>
> 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.
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, please, please, please, just use the info in the
> MODULE_DEVICE_TABLE entries for your autoconfigure program.
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.
> 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.
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.
On Tue, Jan 15, 2002 at 10:34:32AM -0800, Greg KH wrote:
> 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 :)
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
On Tue, Jan 15, 2002 at 01:31:30PM -0500, Eric S. Raymond wrote:
> Greg KH <[email protected]>:
> > Giacomo, please, please, please, just use the info in the
> > MODULE_DEVICE_TABLE entries for your autoconfigure program.
>
> 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.
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]>:
> > 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.
>
> 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.)
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
Greg KH wrote:
> On Tue, Jan 15, 2002 at 01:41:57PM +0100, Giacomo Catenazzi wrote:
>
>>Russell King wrote:
>>
>>
>>
>>>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.
>>>
>>
>>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.
>>
>
> 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 :)
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)
>
> 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.
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.
> 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.
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
On Tue, 15 Jan 2002, Russell King wrote:
> 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.
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