Springen naar inhoud

Operating system of driver?


  • Log in om te kunnen reageren

#1

vw85

    vw85


  • 0 - 25 berichten
  • 14 berichten
  • Gebruiker

Geplaatst op 29 april 2009 - 12:45

Hallo, het verschil tussen stuurgprogramma en bestuuringsysteem is dat een driver bovenop OS werkt terwijl OS bovenop bios en/of hardware functioneert, klopt dit?
Wat mij verwart is dat zowel de OS als de driver ontwikkeld worden om hardware te sturen en af te schermen.

Dit forum kan gratis blijven vanwege banners als deze. Door te registeren zal de onderstaande banner overigens verdwijnen.

#2

meijuh

    meijuh


  • >100 berichten
  • 202 berichten
  • Ervaren gebruiker

Geplaatst op 29 april 2009 - 18:46

Nee je ziet het verkeerd, het os draait bovenop de drivers. Zie ook hier:
http://en.wikipedia....i/Device_driver

Drivers zijn er om een tussenlaag te vormen voor de hardware en OS of applicaties.
Vanwege de tussenlaag is het bijvoorbeeld mogelijk voor een programma om zowel een video te decoderen op een videokaart van NVidia als op een videokaart van ATI. Vroeger, in de eerste veries van MS-Dos waren er vrijwel geen drivers die voor deze tussenlaag zorgde en moesten programmeurs dus hijn eigen software schrijven om bijvoorbeeld de videokaart aan te spreken.

Een mooie illustratie van deze abstractielagen is dit:
Geplaatste afbeelding

Veranderd door meijuh, 29 april 2009 - 18:49


#3

vw85

    vw85


  • 0 - 25 berichten
  • 14 berichten
  • Gebruiker

Geplaatst op 30 april 2009 - 12:34

Nee je ziet het verkeerd, het os draait bovenop de drivers. Zie ook hier:
http://en.wikipedia....i/Device_driver

In computing, a device driver or software driver is a computer program allowing higher-level computer programs to interact with a hardware device.

Wat niet mogelijk is zonder een OS of wel? Zo ja, dan werkt de driver dus bovenop OS, anders is de device zelf een OS!

Veranderd door vw85, 30 april 2009 - 12:35


#4

meijuh

    meijuh


  • >100 berichten
  • 202 berichten
  • Ervaren gebruiker

Geplaatst op 30 april 2009 - 13:28

Het is maar net hoe je een OS definieerd, tegenwoordig hebben besturingssysteem ook scheduling algoritmes om meerdere processen op de CPU uit te voeren (en nog veel meer andere functies).
In principie kun je niet zeggen dat het device zelf een os is maar wel dat een device een os heeft. Namelijk de firmware.

Die abstractielagen waar ik het in de post hierboven over had zorgen ervoor dat machine taal( nulletjes en eentjes) voor een persoon makkelijker te begrijpen zijn.

Algemeen geldt:

Machine: Meest begrijpelijk voor machine <---> Minst begrijpelijk voor machine
Taal: Machine taal - Assembly - programmeertaal - Gebruikers interface
Mens: Minst begrijpelijk voor een mens <---> Meest begrijpelijk voor een mens

#5

vw85

    vw85


  • 0 - 25 berichten
  • 14 berichten
  • Gebruiker

Geplaatst op 02 mei 2009 - 17:28

Voor een nieuwe I/O apparaat (bijvoorbeeld via USB poort) moet je een device driver schrijven, de bedoeling is dat OS dit nieuwe I/O apparaat kan (h)erkennen. OS bepaalt hier wat en wanneer dit nieuwe apparaat zijn I/O lees-schrijf jobs mag doen, en device driver bepaalt hoe het apparaat met OS moet communiceren, op basis daarvan denk ik dat stuurprogramma soms een onderdeel van OS kan zijn, en het werkt daarom bovenop OS.

Het is maar net hoe je een OS definieerd, tegenwoordig hebben besturingssysteem ook scheduling algoritmes om meerdere processen op de CPU uit te voeren (en nog veel meer andere functies).

Job scheduling of CPU scheduling want deze twee verwarren mij soms. Ik had geprobeerd te begrijpen op basis van het opstellen van een OS model:

Geplaatste afbeelding
In uitvoering door CPU: actief.

Aan mij werd gevraagd om de begrippen "dispatcher", "CPU", "CPU scheduler" en "RAM geheugen" op dat schema bij te plaatsen. Wa ik denk te doen is dat de toestand "niet actief" in het geheugen geladen is, actief toestand in CPU en het activeren gebeurt in CPU scheduling door de dispatcher.

Nu eenvroudig.

Ik veronderstel dat OS iets uit onze nieuwe apparaat moet lezen of ernaar moet schrijven:
Geplaatste afbeelding
Hier ergens moeten ik dus een onderscheid maken tussen "CPU scheduler" en "JOB scheduler".
Een process vereist een instructie uit onze nieuwe I/O apparaat, deze proces wordt tijdelijk geblokkeerd, response tijd duur langer van en naar I/O module. Als de job gereed is, dan geeft het een signaal naar "ready" om verder te gaan met het uitvoeren van de proces. Wat bepaalt wat en wanneer in deze actie dan?

#6

meijuh

    meijuh


  • >100 berichten
  • 202 berichten
  • Ervaren gebruiker

Geplaatst op 02 mei 2009 - 19:40

Job scheduling wordt gebruikt om te kijken welk process in het geheugen geplaatst moet worden. Processen die eenmaal in het geheugen staan worden gestuurd door de cpu scheduler. Verder heb je zelf een goede beschrijving gegeven van de toestanden van processen.

Verder moet ik nog even opmerken dat bij usb2.0 apparaten niet op basis van polling werken, zoals jij zegt. Maar op basis van interrupts. Bij polling kijkt de CPU of een apparaat wat wil vertellen, bij interrupts zegt het apparaat dat het wat wil vertellen. Het laaste is natuurlijk veel optimaler.

De CPU scheduler bepaalt wat voor actie er moet gebeuren en wanneer. Enkele algoritmen die je eens zou kunnen opzoeken zijn: first-come-first-served, multilevel feedback-queue, multilevel queue, priority, round robin, shortest remaining time first en shortest job first.
Bovenstaande algoritmen worden in verschillende omgevingen gebruikt, zo wil je liever in een "hard real time" systeem een priority scheduler gebruiken, in een "soft real-time" systeem wil je misschien wel een shortest job first algoritme gebruiken. Een voorbeeld van een hard real time systeem is een boeing 747.
Verder is er bij (sommige) van de bovenstaande algoritmen een kans op "starvation".

Veranderd door meijuh, 02 mei 2009 - 19:41


#7

vw85

    vw85


  • 0 - 25 berichten
  • 14 berichten
  • Gebruiker

Geplaatst op 02 mei 2009 - 22:27

Dank u, die algorithmen zijn erg belangrijk om te begrijpen hoe dispatcher werkt om CPU scheduler zijn werk te laten uitvoeren.

Job scheduling wordt gebruikt om te kijken welk process in het geheugen geplaatst moet worden.

Is een proces in het geheugen plaatsen dan niet een procescreatie soms? Die komt er, volgens mij, tot stand na ingrijp van de eindgeruiker of proces parent (indien de proces een child) of door het systeem zelf. Ik dacht dus job scheduler vertelt CPU scheduler welke processen actief zijn.

Starvation en deadlock treden op bij concurrentie tussen processen en of thread, ongeacht welke alogrithme de dispatcher gebruikt om processen .. Waar ik ze juist moet plaatsen is de kwestie die ik misschien (nog) niet in onder de knie heb.

Ik ga hier een uitgebreider OS model aankaarten, en trachten de technieken en/of resources bij de juiste actie te plaatsen:
Geplaatste afbeelding

"Geblokkeerd/opgeschort" is in feite een swapping (HD en RAM)
"Gereed" en "geblokkeerd" (RAM)
"Gereed > disparch < actief" (SPU scheduler en CPU)

Job scheduler bepaalt dat een proces na de creatie "gereed" of "gereed/opgeschorst" wordt, maar misschien activeren en opschorten tussen "gereed" en "gereed/opgeschorst" is ook een taak van job scheduler .. enzovoort; Alle taken die ervoor zorgen dat de CPU op de hoogte wordt gebracht welke processen er actief zijn, worden uitgevoerd door job scheduler, en CPU scheduler bepaalt welke proces en/of thread(s) wanneer en volgens welke selectie criteria (algorithme) "actief" mag worden, de selectie uit de wachtrij wordt bepaald, vaak afhankelijk van situatie, en dit is OS postprocessing.

Dit OS model dat ik hier heb aangehaald is niet voldoende om de principes van een OS duidelijk in te zien. Een betere uitgebreider model is nodig om de onderstaande principes te visualiseren.
Job scheduler, dispatcher, CPU scheduler, OS postcreatie, proces-synchronisatie en wederzijdse uitsluiting, deadlock, geheugenbeheer, virtuele geheugen en I/O beheer.

#8

meijuh

    meijuh


  • >100 berichten
  • 202 berichten
  • Ervaren gebruiker

Geplaatst op 03 mei 2009 - 11:05

[quote]Starvation en deadlock treden op bij concurrentie tussen processen en of thread, ongeacht welke alogrithme de dispatcher gebruikt om processen .. Waar ik ze juist moet plaatsen is de kwestie die ik misschien (nog) niet in onder de knie heb.[/qoute]

Starvation komt voor wanneer een process nooit uit de blocked state komt.
Een deadlock kan voorkomen wanneer een process wacht op het vrijkomen van een resource, terwijl een ander process die deze resource nu gebruikt weer wacht op een ander process.
Geplaatste afbeelding
Je ziet hier dat er een cycle is tussen R2,P2,R3 en P3.
Het voorkomen van deadlocks kan gedaan worden met mutex variabelen en semaforen. Starvation en deadlocks zijn dus twee compleet verschillende dingen.

Verder kan ik niks zeggen over os postprocessing en het model van de statussen van processen die je hebt weergegeven en ik betwijfel ook of beide dingen wel echt bestaan, aangezien ik er weinig over kan vinden.

Verder ben ik ook van mening dat je niet eenvoudig een model kan weergeven van een OS omdat daar gigantisch veel aspecten bij komen kijken.

#9

vw85

    vw85


  • 0 - 25 berichten
  • 14 berichten
  • Gebruiker

Geplaatst op 06 mei 2009 - 00:14

Verder kan ik niks zeggen over os postprocessing en het model van de statussen van processen die je hebt weergegeven en ik betwijfel ook of beide dingen wel echt bestaan, aangezien ik er weinig over kan vinden.

Verder ben ik ook van mening dat je niet eenvoudig een model kan weergeven van een OS omdat daar gigantisch veel aspecten bij komen kijken.

postprocessing, misschien draait het hier om "pré-emptieve onderbreking" van een proces!?
heeft starvation altijd te maken met blokkeren van een proces in de blocked state? wat als een proces niet uit zijn geswapte (opgeschorst) state kan omwille of uit "greed" state?

ja, eigenlijk begin ik ook te geloven dat een volledige model wat lastig is, maar meer in het algemeen om volledig inzicht in de werking van OS te houden, is een ander verhaal, en dat probeer ik.

grr





0 gebruiker(s) lezen dit onderwerp

0 leden, 0 bezoekers, 0 anonieme gebruikers

Ook adverteren op onze website? Lees hier meer!

Gesponsorde vacatures

Vacatures