> 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
