Messages in this thread | | | Subject | Re: Please!! Help me to help us to use WinModems in Linux | Date | Fri, 09 Apr 1999 16:19:12 +0100 | From | David Woodhouse <> |
| |
rhw@BigFoot.Com said: > Personally, I'd prefer to see the winmodem drivers appear as userland > daemons with the absolute minimum of kernel code included to allow > them to be used. Reasons, in no particular order, include:
> 1. Less kernel bloat. The tool will only be in memory when it's > actually in use, whereas kernel code is normally a permanent > feature of the memory map.
Isn't that what modules and kmod are for?
> 2. Libraries. Userland tools can make full use of the standard > libraries such as libc which are not available to kernel code.
I doubt that much of libc will prove to be useful for the purpose of driving Winmodems.
> 3. Easier development. In my experience, it's much easier to debug > userland stuff than kernel code.
Depends on your viewpoint, and your average caffeine intake. Either way - it's not a valid criterion on which to base such a choice - unless the technical merit of either possibility is so close that it makes sense just to choose the easy one.
However, Winmodems are often likely to require some approximation of real-time response from the driver, and the best place to put that is in the kernel.
There's a case for putting the AT command set emulation in user-space - in fact I'd go further and say there's a case for abolishing it altogether. Use ioctls for the various commands instead of AT-codes, and provide a library which opens and accesses the device on behalf of the client programs - cf. SANE and ESD.
---- ---- ---- David Woodhouse David.Woodhouse@mvhi.com Office: (+44) 1223 810302 Project Leader, Process Information Systems Mobile: (+44) 976 658355 Axiom (Cambridge) Ltd., Swaffham Bulbeck, Cambridge, CB5 0NA, UK. finger dwmw2@ferret.lmh.ox.ac.uk for PGP key.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |