> 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/