> I suppose it is possible that devfs could be faster, however, there are
> significant amounts of policies that can never be done in devfs which
> must be done in user space. For these types of applications, it makes
> sense to provide the fastest mechanism available, even when it may only
> improve boot performance by 1 second.
Eh? Why must you completely re-engineer a solution because you see the
current one as deficient? Not only is it completely over-engineered by
enforcing your fanatical ideas about requiring a new system daemon, but
it's total pre-mature optimization.
On top of that, you don't have any accurate numbers to back up your
claims. Please perform and post the timings I suggested yesterday, and
then we'll talk.
> I understand what you mean by saying that 99.99% of users don't care
> about availability. While those particular users may spend significant
> amounts of time improving Linux, it is the remaining folks that care
> about availability that are interested in investing money into r&d to
> improve availability while also improving feature set. It is this set
> of folks, (the people that do care about availability) that this patch
> is targeted towards.
Then it is your responsibility to merge the continuing efforts and design
goals of the kernel with the requirements of your high-paying customers in
the smoothest possible way. Serving one while ignoring the other is a good
way to waste a lot of time and money.
I care about availability. But, I am not willing to integrate or support
features that come from some random person just because they claim to
improve availability, especially when a) I don't like the numbers and b)
there are no numbers to back it up.
> >As for the memory issues, if no one ever reads from the character node,
> >it will constantly fill up with events, right? Shouldn't they be
> >eventually flushed out at some point in time?
> This is a problem... I wasn't quite sure how to handle this. The two
> choices are to include timeouts in events (after a certain amount of
> time, events are timed out and freed) or to allow only a certain number
> of events, after which events at the front of the queue are flushed.
> The reality though, is that the user will be running the daemon to clear
> out the events. If they don't, then they get what they deserve :)
And this improves availability how?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jun 15 2003 - 22:00:37 EST