Thanks Rene, >Yes, there's no such thing as a stdout in the kernel. Much as I thought. >It means your library has been written for user-space use Correct. >and might very well do more that's N/A >in the kernel. I may be able to get the source code for their library if I try hard enough, but I'm not sure I could identify anything else in there that shouldn't be done in-kernel. >You don't need timers or anything as it's user-space that's setting the pace then. I need to update the register periodically, irrespective of when user-space talks to me. Looks like I'm probably better off just writing a user-space app for this one. Thanks for your input. Leigh. -----Original Message----- From: Rene Herman [mailto:rene.herman@xxxxxxxxxxxx] Sent: Friday, 23 November 2007 6:45 PM To: Leigh Sharpe Cc: kernelnewbies@xxxxxxxxxxxx Subject: Re: STDOUT, procfs On 23-11-07 01:36, Leigh Sharpe wrote: > I'm about to start work on a new kernel module to suit some hardware I > have here, but I had a few questions which need answering first. > > The object of the module is simply to update a register in the hardware > at regular intervals. I intend to rip off the sample at > http://www.tldp.org/LDP/lkmpg/2.6/html/x1211.html , and place my own > functions in the interrupt handler to do the job. The hardware > manufacturer has supplied a library of pre-compiled functions to talk to > the hardware for me. However, the functions in the library all print > information to STDOUT when they are called, and there's not much I can > do to stop it. Is this a bad thing? Yes, there's no such thing as a stdout in the kernel. It means your library has been written for user-space use and might very well do more that's N/A in the kernel. I'd personally advice to simply figure out what the library _does_ and just do so yourself. Given that it seem to consist of writing a value to a register this isn't likely to be hard. A debugger will prove useful. > What happens when a kernel module attempts to write to STDOUT (or STDERR, > for that matter, I'm not really sure yet which one it uses)? Doesn't matter, neither exists. The library is going to "write to STDOUT" by calling a library function such as printf which you are going to have to supply at link time yourself and you have the option of supplying a function that just writes to the kernel message buffer (printk) or somesuch as an alternative to just doing whetever the library does yourself. (if it's an old DOS thing perhaps that uses BIOS calls, you're going to most definitely need to just reverse engineer the bloody thing). Depending on circumstances you might ofcourse also try asking the manufacturer for something sensible instead. Don't wait for an answer before getting going though... > On another note, I will need to communicate with my module, to tell it > what values to write. The guide I pointed out has procedures for writing > to a procfs file from whithin a module, but I can't see anything on how > to get information from userspace into the module, ie how can I pick up > if somebody writes to my /proc file? This sounds like designing the wrong way around. Don't read from user-space but have user-space write to you. The easiest way is registering a character device that user-space writes the value to (in whatever format). Your module can be extremely simple at that point. Just write to hardware whatever you got from the user in the .write() char device method and _when_ ever you got it. You don't need timers or anything as it's user-space that's setting the pace then. If you really do need to write to the hardware even when user-space hasn't provided you with something new to write yet it might need to be more complicated but this seems unlikely. > I also saw somewhere on kernelnewbies.org that procfs is deprecated and I > should use devfs instead. Can anyone point me to a howto on using devfs? devfs is the obsolete one. For information on writing character device drivers (and lots more) read "Linux Device Drivers". It's available online and from book-shops. Otherwise, good luck. Rene. -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
