From: cross@spitfire.i.gajendra.net   
      
   In article ,   
   James Harris   wrote:   
   >On 22/03/2023 12:04, Dan Cross wrote:   
   >> In article ,   
   >> T. Ment   wrote:   
   >>> On Wed, 22 Mar 2023 00:14:38 -0000 (UTC), Dan Cross wrote:   
   >>>   
   >>>> is anyone here actually working on developing real, novel   
   >>>> operating systems on modern hardware here?   
   >>>   
   >>> Novel or not, an OS can't go far without device drivers. For that you   
   >>> need manpower. I don't see much around here.   
   >>   
   >> This is true.  It strikes me that there are options here.   
   >>   
   >> Virtualization with emulated devices is the obvious one.   
   >> While it doesn't eliminate it, this at least limits the scope   
   >> for drivers one must implement, if one is willing to use, say,   
   >> virtio for things like block storage, networking, etc.   
   >>   
   >> Another option would be to use something like a rump kernel to   
   >> provide drivers for actual devices.   
   >>   
   >> Porting drivers from existing systems is always an option,   
   >> though one that is a fair bit more labor intensive than the   
   >> others.  Still, for a particularly complex device, it may be   
   >> less overall effort than building a new driver from scratch.   
   >   
   >Perhaps one's OS could provide an environment in which Linux device   
   >drivers could be run, and the OS build process would be able to take   
   >driver source code from the Linux source tree.   
   >   
   >Both steps should happen automatically, AISI, so while there would   
   >indeed be a bunch of work to get the system set up there would be almost   
   >zero work to add each driver.   
   >   
   >I should say I haven't looked in to the details so the amount of work   
   >may be prohibitive but ATM it sounds like the most promising way to get   
   >access to thousands of device drivers in one's own OS.   
   >   
   >My personal preference would be to run 'foreign' device drivers in a   
   >protected environment where they could not break anything in the kernel   
   >by writing to a rogue pointer.   
   >   
   >As it happens, I was looking at a video on writing a Linux device driver   
   >earlier today. In case someone wants to know the basics, this sets out a   
   >few options for a character-device driver:   
   >   
   >   https://www.youtube.com/watch?v=pIUTaMKq0Xc   
      
   Yeah, that's hard for anything non-trivial.  Linux intentionally   
   has little in the way of internal interfaces, so one finds that   
   drivers for complex devices quickly become entwined with much of   
   the rest of the kernel: memory and process management, storage   
   internals, and so forth.  To bring in a Linux driver often means   
   providing shim interfaces for much of the Linux kernel, which   
   can force an overall "shape" onto the driver that one may not   
   want.   
      
   That said, I've ported drivers that are themselves very complex,   
   but where the overall interface to the rest of the kernel was   
   relatively small.   
      
   	- Dan C.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)