Po co ustawianie trybów jądra zamiast rozdzielania uprawnień?

Ustawienie trybu jądra na początku było trochę bolesne, ale teraz jest całkiem niesamowite. Mam na myśli, że X nie musi działać jako root? Konsole przyspieszane sprzętowo w wysokiej rozdzielczości? Fajne rzeczy.

Problem w tym, że wiele platform UNIX nie ma żadnych sterowników jądra do ustawiania trybu. Sprzęt oparty na KMS jest teraz w większości ograniczony do Linuksa.

Moje pytanie: po co właściwie to implementować w jądrze?

Jeśli do ustawienia rozdzielczości ekranu potrzebny jest dostęp sprzętowy, dlaczego nie użyć osobnego uprzywilejowanego demona lub małego pliku binarnego setuid? Zapewniłoby to korzyść polegającą na oddzieleniu uprzywilejowanego kodu i umożliwieniu serwerowi wyświetlania działania jako ograniczonego użytkownika; jednocześnie eliminując specjalne wymagania dotyczące sterowników i ułatwiając obsługę wielu systemów UNIX. Dobrze? A może brakuje mi tutaj czegoś ważnego?

kernel xorg drivers

— DanL4096
źródło

To jest idea architektur systemu operacyjnego mikrojądra .

— Barmar

W tym przypadku nie myślę o modelu typu mikrojądra, a bardziej o przenośności między różnymi jąderami.

— DanL4096,

KMS jest również używany przez OpenBSD i FreeBSD, a Solaris ma również KMS w trakcie pracy. W ten sposób, gdy programiści stworzą działający sterownik dla Linuksa, obsługa sterowników przejdzie również do innych użytkowników korzystających z KMS.

— hspaans

To rzecz architektoniczna. Dostęp sprzętowy to jedno, jeśli nie THE, zadanie jądra. Podział pracy pomiędzy jądro i przestrzeń użytkownika jest niewygodny, ponieważ będziesz potrzebować dwóch komponentów, które faktycznie wykonują tylko jedną pracę z rozmytym interfejsem. Ostatecznie wykonasz pracę w domenie jądra, dlatego jest mocny argument za umieszczeniem całej rzeczy w jądrze. Oczywiście możesz go jednak wdrożyć i gdziekolwiek chcesz. W solidnych platformach chodzi o wyraźnie (!) Zdefiniowane architektury i interfejsy. Wszystko jest chwiejnie chwiejne.

— Bananguin,

Był dość długi okres, w którym różnego rodzaju awarie powodowały, że konsola znajdowała się w dziwnym trybie, w którym X już nie działał, ale dostęp do konsoli w stylu TTY nie został w rzeczywistości przywrócony. Problemy z przyspieszaniem IIRC GL i awarie używane do dość częstego wywoływania tej sytuacji. KMS oznacza, że jądro wie, jak rozwiązać problem i przywrócić stan konsoli. IOW częściowo poprawia użyteczność. Chociaż można argumentować, że jądro może poprosić o to demona przestrzeni użytkownika, myślę, że nie zawsze działa to dobrze. Również umieszczenie go w jądrze oznacza brak problemów z zamkniętym źródłem.

— James Youngman

Jądro już zarządza sprzętem sieciowym, sprzętem audio, wentylatorami i innym sprzętem, więc ma sens, że sprzętem graficznym zarządza również jądro.

— Alexander
źródło