Thanks for your feedback. Now, I think I am going to start by trying to understand a little about the Dev interface you talk about, and then continue to write a real driver for a gamepad that I have. Is there any documentation that describes this Dev interface? This is a usb gamepad, so probably I have to deal with a Dev interface related to the usb ports, am I right?
Hugo 2008/4/15, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: > > 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 > > >
