Date: Sat, 15 Aug 1998 01:11:00 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: hm@kts.org Cc: tlambert@primenet.com, freebsd-hackers@FreeBSD.ORG Subject: Re: developing device drivers Message-ID: <199808150111.SAA02595@usr04.primenet.com> In-Reply-To: <m0z7DYh-00000hC@bert.kts.org> from "Hellmuth Michaelis" at Aug 14, 98 08:41:55 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > You probe and attach at load time, normally. This means you detect the > > IRQ/DRQ/IOBase/MemBase/Etc., not assign it. > > I don't quite understand, sorry. > > Given an ISA card, supporting IRQ's 3..15, i/o 0x100...0x300 and mem 0xa0000 > ...0dffff. > > What i was looking for in the first place was something like > > modload -I <irq> -O <iobase> -M <membase> .... > > to specify the same parameters i'd have to specify in the kernel config file. > > When i probe at load time, i try to detect the card in question, but where > shall i start to search without knowing _where_ to search (iobase/membase) > (other than searching through the whole supported iobase/membase) ? > > Given i found the card to be the one i looked for, which of the > IRQ/iobase/mem supports shall i use in the attach ? How is the user to > be able to specify the parameters he prefers ? In general, the answer is that the modload can't communicate this information to the driver. The problem here is that there may, in fact, be a large amount data to communicate, and there's no agreement between the driver and the lkm device about how to marshall this data, or even what data to marshall, across /dev/lkm; or in fact, what code you would have to put in the driver to "catch" the data. So modload would not know where to begin to get this data into the device in a useful way. On top of this, it is generally undesirable to have to communicate this information from the hardware, through a human, to the driver; doing this has really bad consequences when you attempt to dike the human out of the picture and have the driver demand-loaded into the kernel. Especially if the driver is needed for booting, and the kernel pulls it out of an mfs, for example. The best answer is that the driver needs to be able to find its hardware. If this is impossible, and the only way it is physically possible to detect the hardware is either through a destructive probe that may render the machine unstable, or through a human telling the driver where the hardware is, *AND* the human can't edit a config.h header and recompile the driver (lacking one of source, tools, or brains), then you have several options: 1) Supply the information in a seperate "config.c", which the user compiles, and then uses "ld -r" to make a single object file, which is then used for the modload. The only requirement for a module is that it reside in a single object file; a module need not reside in a single compilation unit (in fact, modload depends on this being true). I call this the easy approach. 2) Make the probe do nothing and make the attach create a pseudo-device instead. Supply a user space program that the user runs to configure the driver in a device-specific way, communicating the configuration via ioctl()'s over the pseudo device (this is how the LKM system started life: as a linkable device driver on an SVR3.2 system that let me twiddle kernel structures, mostly because gcc of the day didn't support PIC code until Jeffrey Hsu added it). The last act of this user space program would be to say "become the real device when I close you". I call this the Pinnochio approach. 3) Use a configuration file, and use kernel level file I/O to retrieve the information from the file at driver load time. The easiest, safest, least error-prone way to do this is to use the PCMCIA configuration interface, which has already done all of the device classification and file I/O for you, and wrapped it in a nice (well, an OK) API. I call this the leech approach. Obviously, it would be better if your device had a ROM associated with it, and you usesd the kernel md5 to see if it was the ROM for your device, and then probe it safely from there. If the reason you can't probe the device is lack of information, your best bet is to take the DOS/Windows drivers that devices without programming information inevitably come with, and have a friend in a country with mostly sane ideas of intellectual property law not equalling a God-given right to not sell products on equal terms regardless of who is buying them, like Germany, run a copy of "Sourcer" from V Communications, Inc. (this is Frank van Gilluwe's, author of _The Undocumented PC_, company) on the driver for the purpose of documenting the hardware interface. Which puts you back in the ballpark for the best approach: the driver needs to be able to find its hardware. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808150111.SAA02595>