Re: [9fans] Writing drivers in Plan 9
Sadly I cannot find time for Plan 9 for now. I am just too busy with my job in the university and preparing me for some tests in October. Hopefully I can start this thing in November. 2008/9/3 Tom Lieber [EMAIL PROTECTED]: On Tue, Apr 15, 2008 at 4:40 AM, hugo rivera [EMAIL PROTECTED] wrote: Anyway, I've always wanted to learn to write drivers and I did try it a few years ago, using NetBSD, but I could not find time to complete the task, so I leaved it unfinished. I want to start again, but this time using Plan 9. So, I want to ask you for some pointers about how doing this. Please, bear in mind, that I am a complete newbie when it comes about writing drivers. Did you do it? How did it go? -- Tom Lieber http://AllTom.com/ -- Saludos Hugo
[9fans] Writing drivers in Plan 9
Hello: I've been using Inferno and Plan 9 for almost a year. I certainly love Plan 9's ideas and concepts, and I'd be glad to finally move forward and leave Unix behind, but for now it is imposible for me, since my work does not allow me this (I do data analysis for some physics experiment using Cern's ROOT). Anyway, I've always wanted to learn to write drivers and I did try it a few years ago, using NetBSD, but I could not find time to complete the task, so I leaved it unfinished. I want to start again, but this time using Plan 9. So, I want to ask you for some pointers about how doing this. Please, bear in mind, that I am a complete newbie when it comes about writing drivers. Saludos Hugo
Re: [9fans] Writing drivers in Plan 9
Given that you're already into Inferno as well as Plan 9, I think a really nice way to get into driver development is with emu drivers for Inferno. The basic structure is the same as for native OS drivers in either system: implement a small set of entry points (fooattach, fooread, c), making use of the dev* defaults where appropriate. It's then a much smaller step to move into native hardware drivers for Plan 9 or Inferno. And when you do get to that point, take a look at Inferno's os/port/devXXX.c; it's a template for what you need to implement. In any case, the devtab (look for '^Dev') towards the end of any driver will tell you what you really need. It's a much nicer, constrained set for Inferno and Plan 9 than any unix. Anthony i think this confuses implementing a Dev interface with writing a device driver. for many devices, the Dev interface is already taken care of. for example, serial, ethernet, disk devices using sd implement an interface to devsd, ethernet. i don't buy the thesis that talking to hardware is always hard. talking to some hardware can be hard. for exampe, the aoe driver doesn't talk to hardware, it talks to the ethernet drivers. yet it's the largest driver i've written, largely because it implements its own dev interface. i think it's a mistake to think hardware == hard, software interfaces == easy. - erik
Re: [9fans] Writing drivers in Plan 9
i think this confuses implementing a Dev interface with writing a device driver. for many devices, the Dev interface is already taken care of. for example, serial, ethernet, disk devices using sd implement an interface to devsd, ethernet. i think the Dev interface is still the right place to start, in terms of understanding things. for the benifit of the original question, the Dev interface (that common set of entry points i was talking about) is the common kernel interface that all device drivers have to go through at some point. i think part of erik's point (which is correct) is that many of the things people are commonly writing drivers for - disk controllers, ethernet cards, and vga cards being probably the most common examples - already have that interface covered, and there's a separate interface that the hardware-specific part needs to talk to. i don't buy the thesis that talking to hardware is always hard. talking to some hardware can be hard. for exampe, the aoe driver doesn't talk to hardware, it talks to the ethernet drivers. yet it's the largest driver i've written, largely because it implements its own dev interface. but working with Dev doesn't need to be so complex; it depends, at a minimum, on what the job you're trying to do is. dup and env both implement at least most of their own Dev interface (as opposed to relying on many of the default stubs), but are reasonably short and easy to understand. devaoe's hardly a fair comparison; it's not only the largest driver you've written, it's the largest dev*.c in the system. i think it's a mistake to think hardware == hard, software interfaces == easy. agreed. but it's also a mistake, at least in the context of Plan 9, to assume that device drivers inherently involve hardware. about a third of the things in section three of the manual don't. anthony
