Easily recognizable API? If there is a joke, it's what libc is doing to POSIX API.
Forget about POSIX. We don't have open/read/write/close because of POSIX, but because it's a common sense API. Not fancy, but if only thing you care about is opening some stream of bytes (something the user points you to via a string name), reading some bytes from it and then closing it, you should not need anything fancy.
Now to address your other reservations. POSIX API does not consider separation of names and identities. For POSIX, a name is what the file it.
Again, forget about POSIX and don't inflict any semantics on the API that isn't actually there. The only thing you care about are the file handles that identify opened streams of bytes. Everything else goes beyond that. The first argument of open() is usually a path name, but it can be anything else.
By the way, for most practical purposes, you should use <stdio.h> anyway.
In many cases yes, but stdio.h is already a high-level API, with possible buffering, etc. We are talking about the low-level API here.
As you noticed, currently, the structure only wraps the file handle. This change is very recent and made in preparation for client storing much more information. The client will become a little fatter, and the library itself is intended to do much more than the VFS server.
Well, my opinion is that if you want to make the client fatter, put the fat stuff into the FILE structure. But keep the low-level API simple and stupid.
You can see numerous examples of such approach in the code (e.g. the low-level IPC API vs. the async framework).
The actual reason for that is symbol clashes with the server code. You can't use vfs_ prefix without a lot of conflicts. That is the price for using C.
Well, obviously there was no such issue with open/read/write/close :) Also there are nicer ways to deal with that, see again loc_*, devman_*, etc.
If you need to avoid symbol clashes, make the names on the server side longer, not the symbols on the client side.
Because nobody else has thought of moving non-standard HelenOS specific functions into a separate directory, yet.
No, you are just missing the entire history of HelenOS. Understandably, this idea actually crossed our mind a long time agou, the user space libraries were implemented like that for some time (anybody still remembers libipc?). But we have abandoned the idea.
Look, there is just nothing "non-standard" with respect to HelenOS libc. It is our libc, it is our primary user space API and it is "standard" for HelenOS. Just keep thinking about it in this way.
Propose a better one.
I don't know, that really depends on what it should do, in general. But maybe something like "repository" or "depot"? "Inbox" has too much of the "receiving email" connotation for me.
Some of these issues can be addressed, but for example leaving out argument names in function declarations is the worst idea ever to enter programming world.
Well, get over it. It is our coding style. Perhaps learn how to use some good IDE for code completion and navigation or at least use cscope.
As for statfs(), I just merged it from the mainline yesterday night.
OK, sorry about that.
Wasn't it you who very specifically made it clear that combining files with non-file objects is what you want to avoid like plague?
Oh, come on, now you are just trolling. I was talking about not _making_ a file from something that is not a file (i.e. avoiding the "everything is a file" paradigm).
Now I am talking about generalizing a data structure from a means to propagate the information about open files (stdin, stdout, etc.) to a means to propagate also different kinds of information.
It's a pipe. What could it possibly do? Maybe you are confused by the fact that the library call to MKPIPE is missing.
I was confused because I saw no direct connection to the rest of the VFS overhaul. Still, coukd the code make use of the generic producer/consumer ADT instead of implementing the logic manually?
VFS test is removed now simply because it tested the old API. It makes little sense to write tests for API that may change or be rejected completely.
Never heard about test-driven development?
"kill" and "killall" programs have no value outside user shell. This is probably a matter of personal taste, but the way processes are managed by user is subject to shell implementation
What you are describing are shell jobs. But "kill" and "killall" are not meant for job management, but as administrator's tools.
I can imagine many ways a shell could make it possible for user to terminate misbehaving programs. "kill" command is one of the uglier things I can think of.
Again, "kill" is not meant as a way users should normally terminate their applications. They should use the top-right cross of the window (in case of a GUI shell) or a job control command (in case of a CLI shell), I agree completely with you.
But the system administrator might still like to have a standalone, brute-force command for terminating a task. Or something like a task manager for the GUI.
You do understand that with all the response I am getting for various proposals here (which is, next to none), keeping this outside the mainline means more private changes I get absolutely no feedback on. Unless you guys actually participate in external branches, doing any work on HelenOS short of complete fork is pointless. You could have subscribed to my branch more than a month ago and dispute my changes as I was making them. Instead, you wait for me to say "I am happy with this" just so that you could say you don't like half of it. Not helping.
Jiri, please put your ego aside for a minute and stop exaggerating. You are far from being the only one who is working on something outside the mainline. If you really want to experience "no reaction to your proposals", that is really easy to arrange, and you being resentful and negative is the first step towards it.
This feedback is simply the best I can give you. I don't know how about you and the others, but I am rather busy and following anyone's branch on a daily basis is just impossible for me. But if you signal that you consider the branch ready for merging, I look into it and tell you my opinion. What more do you actually expect?
It is understandable that you are extremely enthusiastic about your ideas and code, but please just cope with the fact that not everybody else is required to be as enthusiastic as you are.
Additionally, there is a huge gap between theoretical proposals and actual code. I liked your thesis in general, but you know from the meeting in Brno and previous hangouts that I have great reservations towards some of the practical ends you want to implement it. My previous email was well in the line of these reservations.
You just can't sell me by introducing a client-side change that affects virtually all applications without any obvious client-side benefit (at this time at least).
I might cherrypick interesting bits and pieces from your branch later, but I myself won't merge it as-is at this very moment. I think it needs more love and maturing.
I am not the gatekeeper. There is a dozen of people who can vouch for your code and merge it into the mainline if they really like it. Please just don't make it personal.
Finally, either just fork HelenOS or stop threatening with it. HelenOS is a community open source project which requires consensus, so please learn to live with the fact that not everybody is entitled to support every single idea you have and every single line of code you write.
Nobody has touched the VFS and related code in a while, nobody is making you hard time merging regularly from upstream. Having your own branch is really not such a great deal, I myself have like 20 private branches. You can even help yourself here by keeping your changes conservative, such as not replacing every single call of read() with vcl_read().
M.D. _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
