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.
Laatste berichten
-
22:54
Herleiden afmetingen vanaf een foto 12
-
18:53
Ik wil studeren via afstandsonderwijs, kennen jullie Tech?
-
18:09
Rotatie van het heelal 32
-
17:19
Ervaringen met "herontdekkingen" 12
-
18 apr
hall effect in vloeistof gebruiken als stromingssensor 6
-
18 apr
Gezocht: de/een naam voor een getallenrij met een cauchyrij als partieelsommenrij
-
18 apr
Casus uit de praktijk: positief test THC 18
-
17 apr
speciale rel. theorie 4
-
17 apr
Vreemde stank in huis 11
-
17 apr
3 vragen over mijn rooskleurige r.berekening H2netGekoppeldeHBrflowbatterij.
-
17 apr
Interpretatie reactie-energie 3
-
17 apr
Logistic equation (Pierre Verhulst,Belgian Mathematician) 5
-
16 apr
vB 9
-
15 apr
Kunnen quantum Zonnecellen 190% quantum efficiënt zijn 1
-
15 apr
Python: sockets sluiten 4
-
14 apr
Een eenvoudige logische redenering waarom tijd niet kan bestaan 'daarbuiten' 6
-
14 apr
Hoe kun je op quantumwijze getallen vinden in een rij die kleiner zijn dan getal k 3
-
13 apr
Documentenverdwijnen uit onedrive 1
-
12 apr
Behoud van impulsmoment en energie 5
-
12 apr
INLOG STORING / TIPS 4
Nieuwsberichten
-
04 mar
Een nieuw soort magnetisme: altermagnetisme
-
31 okt
AI kan via stem diabetes vaststellen 11
-
21 okt
Einstein krijgt wéér gelijk 45
-
07 feb
witter dan wit 20
-
19 jun
irrigatie en de aardas
Operating system of driver?
-
- Berichten: 202
Re: Operating system of driver?
Nee je ziet het verkeerd, het os draait bovenop de drivers. Zie ook hier:
http://en.wikipedia.org/wiki/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:
http://en.wikipedia.org/wiki/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:
-
- Berichten: 14
Re: Operating system of driver?
meijuh schreef:Nee je ziet het verkeerd, het os draait bovenop de drivers. Zie ook hier:
http://en.wikipedia.org/wiki/Device_driver
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!In computing, a device driver or software driver is a computer program allowing higher-level computer programs to interact with a hardware device.
-
- Berichten: 202
Re: Operating system of driver?
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
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
-
- Berichten: 14
Re: Operating system of driver?
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.
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:
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?
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: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 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:
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?
-
- Berichten: 202
Re: Operating system of driver?
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".
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".
-
- Berichten: 14
Re: Operating system of driver?
Dank u, die algorithmen zijn erg belangrijk om te begrijpen hoe dispatcher werkt om CPU scheduler zijn werk te laten uitvoeren.
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:
"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.
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.Job scheduling wordt gebruikt om te kijken welk process in het geheugen geplaatst moet worden.
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:
"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.
-
- Berichten: 202
Re: Operating system of driver?
[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.
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.
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.
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.
-
- Berichten: 14
Re: Operating system of driver?
postprocessing, misschien draait het hier om "pré-emptieve onderbreking" van een proces!?meijuh schreef: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.
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
