Hi Jiri,
It has taken me a bit longer than I expected, but the current state of
my repository is that it can be merged (modulo possible bugs), and
further additions won't have so much impact on the rest of the system as
they had until now.
Thanks for your email. I am sorry to disappoint, but in my opinion the
branch is still far from being mergable into mainline. A few reasons for
that:
* I consider your vcl_* API more like a joke. You replace an easily
recognizable API (that is, of course, not 100 % standard compliant, but
still close enough for most practical purposes) with a totally alien
API, with absolutely no benefits to the user. The client-observable
behaviour is mostly the same, it still uses a file handle, only
strangely packed in a structure.
Until you really start doing something totally new and unheard of, I
suggest you stick with the API everybody would recognize. And even if
implementing something new, an extension of the existing API seems to be
better than just reinventing the wheel. Of course, HelenOS is an
experimental OS and we are not afraid of taking our own ways, but we are
also not afraid of reusing existing concepts and APIs where it is
appropriate.
* Consistency: To avoid unnecessary confusion, we try to keep the client
names the same as the server names. We don't have LSCL ("Location
Service Client Library") and so on, therefore I see no reason for a VCL
("VFS Client Library").
Also, why is the vcl_* stuff as the only thing in the "helenos"
subdirectory of the libc? And as a nit, I don't consider the "inbox"
name very fitting.
* Coding style: Major issues. You do not respect the 80 characters per
line rule, some definitions of macro constants are mixed with functions,
some files are without copyright headers, some header files contain
external symbol declarations without the "extern" keyword and with
argument names, there are some really dense functions with no horizontal
separators (statfs()).
* Integration: The "inbox" idea is interesting, but while you do it, why
not extend it further to non-file objects as well? We still lack the
equivalent of environment variables and this might be a handy way for
pointing the spawned task also to other resources (e.g. the compositor
in case of GUI tasks, etc.).
* VFS server: I fail to see the reason for the pipes. What does it do,
actually? If it is really just a producer/consumer, we already have a
generic support for that in libc (adt/prodcons.h).
* I might be mistaken, but you though away some functionality from the
mainline (like in the cat command or the lack of a VFS test) for no
obvious reason.
* As a bottom line: I fail to see the reason for your comment in "kill"
and "killall" that the commands should be integrated into a shell. In my
opinion it is the other way around, many current internal bdsh commands
should live as separate binaries. They are currently in bdsh only to
save some footprint until the dynamic linking is fully supported.
The only case where I agree with you is "redir" (of course, redirection
should be implemented by the shell itself), but redir can still act as a
standalone tutorial of how to do redirections.
To sum up, it is good to see where your code is going, but I would
really prefer to keep this outside the mainline branch for now.
M.D.
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/listinfo/helenos-devel
