Possibly. Tejun and I looked at it a while ago and could not see any
problems that you could trigger by having multiple superblocks share
the same inodes but there might be some. I don't like that aspect
of it any more than Al does, I just haven't found an alternative
that works, nor have I seen a suggestion that is better.
And my point is that compared to the other bugs Al found in sysfs
my contribution is miniscule and minor, and pretty much fixed
at this point.
Do I have to rewrite all of sysfs to the point where Al can not find
bugs in it before I can merge my changes?
If that is the standard while it seems ridiculous I can work with
it. I need something i can work with.
As Serge said. The problem is very simply that with the network
namespaces we create devices in different namespaces that have
the same name. lo being the first one we hit. It wasn't my
idea to export them to sysfs but it has happened.
We need a way to put those devices in sysfs that doesn't break
sysfs and is in some form backwards compatible with code that
is running today.
Given that there is at least one directory per physical NIC
in sysfs that I need to handle, the easiest approach I have
found is simply to have a way of having entries with the
same name in the same directory and have a filter on the superblock
of sysfs so different ones are shown.
The goal is not to hide the fact you are in anamespace. So
information "leakage" isn't a problem. I simply need a configuration
where something works.
If I could do what I am trying to do with FUSE I would be happy to
do it that way, and for more esoteric things I have actively suggested
it.
Sometimes. That has to be balanced against the it is pointless to
submit patches effect. Which I am feeling pretty strongly right now.
A lot of false criticism and what feels like over reaction mixed in
with the few real bugs.
Yes. "years". This last round hasn't been too bad in comparison
3-4 months. Just before the start of the previous merge window to now.
I totally agree. And for that I have no problem if they are not merged
into the stable release. At the same time if they are not at least in
a tree that merges into linux-next no one takes them seriously and the
code is just ignored.
His issues are that sysfs has problems.
Except for one I have already addressed Al's issues that were in my code.
Greg do you understand sysfs well enough to know if I have addressed Al's issues?
Eric
--
