On 15 September 2013 16:05, Martin Decky <[email protected]> wrote: > 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. > > Ok, then I will just point out that using standardized names for non-standard functions is IMHO a very bad idea, and makes working with HelenOS more difficult with questionable benefit.
> 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 low-level API is not supposed to be used by anything else than a higher-level API. Think of it like the library implements some things that could just as well be in the server, but aren't, because the code is much simpler if it's 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. > Well, I have not been here when the decision to mix everything up in libc was made, but I can't believe the reasons were serious enough to warrant such a confusing library. > > 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. > > I will think about it. > 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. > > Honestly, I don't see the difference. > 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? Maybe. I will have to look into that. > > "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. > > My mistake. > 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. > > You could have asked why I chose to do it like this, instead you chose to call most of my free time for a last month "a joke". I am unable to respond positively to that. I really cannot. -- Jirka Z.
_______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
