Re: [uml-user] proc fs and ip address

[Blaisorblade <blaisorblade@xxxxxxxx>]

On Sunday 08 October 2006 18:42, Nic James Ferrier wrote:
> Blaisorblade <blaisorblade@xxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user