O Autodektekcji sprzętu - koncepcja

[Kosmo]

Po zerknięciu do innych distro i chwili przemyśleń proponuję następujące
założenia co do autodetekcji sprzętu w PLD (jak coś robić to porządnie):

Rozdział I - założenia ogólne.

1. Autodetekcja osobno dla instalatora i systemu.

Jeśli system miałby swoją autodetekcję, to zadanie instalatora
ograniczało by się do stwierdzenia czy urządzenie danego typu (np. karta
dzwiękowa) jest w komputerze. Dokładna autodetekcjia była by
przeprowadzana przy starcie systemu. Druga sprawa to szybkość: 10 sec
czekania na wykrycie sprzętu przy instalacji to nic, przy starcie systemu
to bardzo długo. Dlatego proponuję zrobić to dla systemu w perlu / C
(ja preferuję perla).

2. Modularność.

Każdy sprzęt można podzielić na kilka rodzin: karty sieciowe, karty
graficzne, karty dziwiękowe. Każdą z tych kart instaluje się inaczej.
Karta dzwiękowa: moduł + aumix
Karta sieciowa: moduł i ustawienie interfejsu
Karta graficzna: ustawienie framebuffera i X-ów (detekcja monitora).
Dlatego proponuję, do każdego typu sprzętu zrobić osobne skrypty do
autodetekcji. Daje nam to małe skrypty, możliwość zostawienia sobie
przez użytkownika możliwości wykrywania np. tylko kart dzwiękowych.

3. Zapis plików konfiguracyjnych TYLKO W OSTATECZNOŚCI I ZA WIEDZĄ
UŻYTKOWNIKA.

Ten punkt może wydawać się dziwny. Chodzi mi o to, że niektórzy nie
lubią jak jakiś program grzebie im w konfiguracji. Programy nie
są zbyt inteligentne, i mogą zniszczyć misternie napisany plik
konfiguracyjny. Dlatego proponuję, żeby autodetekcja ograniczała
się do załadowania modułu i postego setupu. Jeśli użytkownik
byłby chętny do automagicznej konfigutacji np. X-ów - bardzo chętnie
ale musi się na to zgodzić (i dokłądnie wiedzieć co zostało
zmodyfikowane). Można by też rozwiązać to tak, że istnieje plik
kofiguracyjny - matryca, a instalator posługując się nim tworzy właściwy
plik z configiem. Przykład:

Matryca:

Section "Monitor"
	Identifier      "Monitor 0"
        HorizSync       $HORSYNC$
        VertRefresh     $VERTSYNC$
EndSection
				
I w miejsce $ZMIENNA$ lądują odpowiednie wpisy - dalje nam to calkowitą
kontrolę nad tym co się dzieje w systemie. Więcej o tym w Rozdziale "Jak
wykrywać kartę dźwiękową".

4. Skrypty mouszą tworzyć sobie bazę sprzętu automatycznie.

 .. bo tworzenie takiej bazy ręcznie jest zbyt żmudne.


Rozdział II - Jak wykrywać kartę dźwiękową

1. Baza sterownikow - tworzona w trakcie budowania alsy/kernela. Osobny
pakiet z bazą. Daje nam to automatyczny upgrade bazy przy zmianie wersji
sterowników.

2. Użytkownik ma całkowitą kontrolę nad tym co jest wykrywane -
ustawienia ręczne mają pierwszeństwo. Przyklad:

/etc/modules.conf

alias	sound-slot-0		es1371
alias	sound-slot-others	auto

Ustawiona ręcznie karta jest ładowana najpierw - nie zmieniają się
numery urządzeń w /dev dla danej karty - np. jeśli użytkownik włoży
sobie drugą kartę, to stara dalej siedzi na /dev/dsp0, nowa /dev/dsp1.

3. Skrypt nie modyfikuje żadnych plików konfiguracyjnych - poprostu ładuje moduł i
ustawia mixer. Skrypt zapisujący stan mixera idzie do przeróbki - musi
obsługiwać kilka kart dzwiękowych.

4. Szybkość pracy / Wybór sterowników.
 - Użytkownik musi mieć do wyboru jakich sterowników użyć: Alsy
   czy OSS z kernela:

   auto		- "pierwszy lepszy" z kernela i alsy (kernel preferowany)
   auto-oss	- z kernela
   auto-alsa	- z alsy.

 - Użytkownik ma możliwść zdefiniowania czy szukać karty na PCI czy ISA.
  (Przesukiwanie ISA jest dużo wolniejsze i nie każdy komputer ma ISA)

  auto		- PCI i ISA
  auto-pci	- PCI
  auto-isapnp	- ISA
 
Razem daje nam to opcje: auto, auto-oss, auto-alsa, auto-pci,
auto-isapnp, auto-pci-oss, auto-isapnp-oss, auto-pci-alsa,
auto-isapnp-alsa.

Co o tym sądzicie ?