On Sunday 08 October 2006 18:42, Nic James Ferrier wrote: > Blaisorblade <[EMAIL PROTECTED]> writes: > > That is not a bad attempt, and you show having some uncommon experience > > with kernel code. I'm not reviewing it line-by-line - I should check the > > APIs of VFS calls and usage examples, but I haven't the time. > > Cheers. I've never written kernel code before... Compliments! > but how hard can it > be?
That's a lie, face it... it _is_ hard. Being a very smart programmer helps, but as you say documentation is lacking, so you become able to write good code when you're able to face lack of documentation. > > I can only suggest reading the code of sys_getdents as a starting point. > > I think you could use without problems vfs_readdir instead of ->readdir > > since it accepts a filldir_t callback and does the needed locking you do > > not do. > > > > You very likely race with process creation and exit - as /proc/<pid> > > folders appear and disappear you need some kind of locking. > > Some of the documentation I found suggested that readdir handled all > this by reading the contents of the directory and then presenting > it... atomic in terms of directory modification. It may be true - however since nor you nor I have a complete idea of the locking design, we can say we have no idea; also it may refer to vfs_readdir rather than readdir - ext2_readdir() shows no signs of locking. Looking existing code and copying as much as possible, but also as little as possible (you want to avoid code duplication) is the usual road. > Your comments suggest that I've got the wrong end of the stick there. > > Anyway... I'll try and use vfs_readdir and take a look at doing things > with dentrys. Wait - I think this specific case does not need any work with dentries, it is different from the crash I described. I was giving generic suggestions - afterwards I looked at sys_getdents and found that this one was easier. Finish this patch this way and it can be (IMHO) accepted with interest (after "impedence matching" with kernel standards - codingStyle et similar things). > When I'm rich I'm going to start a linux kernel documentation > project because the current state of the doc of kernel APIs is v.poor. > The thing I find myself needing for kernel hacking is someone to say > "nah... that's the wrong way to do it - go look at x,y and z > instead...". > It's good to know that someone here will do that job. Are you talking of yourself when you are rich or of someone else? > btw I'm also looking at whether I can simply add a proc file for net > device IP addresses. I don't really see why this is not possible given > that the kernel knows this information. The astonishing thing is that /proc/net/if_inet6 has this information for IPv6 ips, but no /proc/net/if_inet6 nor /proc/net/interfaces exists. Mconsole exec would also be useful for this, if it could return output - maybe redirecting to dev/console would do that (to test) or it could maybe be added easily, now. > It's going to take me a lot > longer to fix that problem though... registering stuff with proc fs is > pretty impenetrable. Not at all. This one is documented widely. Just two URLs: http://lwn.net/Kernel/LDD3/ (a definitive reference, oriented for driver writers but useful even here). http://lwn.net/Kernel/ (for updates) -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ User-mode-linux-user mailing list User-mode-linux-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user