"A month of sundays ago Rusty Russell wrote:"
> I put the startpos hack in originally (as shown in comment):
> for reading firewall rules (which can be variable length), I wanted to
> store the rule *number* in the file offset, not the number of bytes
> offset, but didn't want to hack the internal proc interface. I didn't
> try to use it to read > 3k.
OK. I don't know from reading the code whether it will or will not mix
well with the >3K functionality (or even if the latter was planned).
All I can say is that the >3K is apparently working. now that
we have figured out how it was meant to be triggered.
Storing the rule number in ppos seems strange. I think you should
have kept the natural ppos semantics and used a map ppos<->rule index.
I've just gone to a bit of trouble to do just that kind of thing.
Now that I understand that mode, I may submit a patch to stop it! :-)
> The current proc system is a crock of shit: unless you use it
> for a single variable per file (the trivial case) it's hopeless.
> Also, it's messy as all hell (as you've pointed out).
Yes. All I tried to do in this first instance was to make the errors
plain to see, if they are errors! They can be fixed in a second pass.
> Think about it: the very concept of `human readable' output by
> the kernel is flawed. What language do humans speak? There isn't
> much motiviation to try to fix something that isn't really fixable.
Well, I disagree, but that's beside the point. The point is that the
code in question is pivotal. Nearly everything in the kernel uses
/proc. Nearly all of it uses that function in generic.c. And after
cleaning it up it looks a lot better, and clean enough for its
problems - if any - to be visible. If you can comment on the lines
I marked with FIXME, that would be helpful.
> That's why iptables ran screaming back to getsockopt()
> Shit, did I just reopen the /proc wars? Sorry...
Probably.
> PS. I apologize if I broke the Kernel Code of Conduct by saying `shit'
> above. I don't know what the fuck came over me.
Recursion.
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 15 2000 - 21:00:26 EST