Neal,
> My problem is not so much with setting the owner and changing the file
> mode, but rather, using the author field for the creator uid and the
> flags for the pid of the last operation, etc. Please understand that
> I was sloppy as it was not my intention to decide what to overload
> with what data. Rather, I would like to open up discussion and get
> some other people's input. So, more formally, here are what we need
> to save:
I see. I understand. I do agree that the overloaded fields are not
pretty and I was fairly certain that someone would object to that
particular methodology. I have found that sometimes the best way to
get someones attention is to do something "controversial", so I'm
just happy the problem is being worked on.
> No, I think it is acceptable, however, in this particular case, it is
> my opinion that the Hurd rpcs are at a lower level than we need to
> address directly: the libc functions give us enough control and manage
> some of the details. Perhaps others will disagree with this decision,
> please comment.
I see no problem with either approach, I was just curious about why you
had done it this way.
> Generally, Roland has expressed a certain (i.e. an understandably
> large) amount of resistance to any interface changes (e.g. adding any
> new RPCs) without a significant amount of justification. And at this
> point in the discussion, I do not think that we have explored all of
> the possibilities.
As I see it, we have four major alternatives to solve this problem,
each having it's own merits and problems. Note that I am not
making any judgements at this point on the merits or lack thereof
of any of the alternatives I have outlined.
a) Overload existing fields and hope to get enough of them to
work enough of the time.
b) Add additional RPCs to some of the filesystem servers
for the purpose of tracking the data we lack.
b-1) Enhance the filesystem interface as a whole to include PID
and UID/GID of creator and number of file references.
c) Write the data to a plain file or the head of the SHM file.
I really wish there were other alternatives, but I'm hard pressed
to find another one.
> > The problem with putting the data in another file or in the file
> > itself is that it will be nearly impossible to ensure that no-one
> > can come along behind you and corrupt it, remove it, etc.
>
> Well, the same holds for the fields, so, this is not a valid argument.
Yes, this same holds for other fields. This doesn't make this an
invalid argument. It still holds One thing that made me nervous
about the mmap() approach to shared memory was always that the
file was accessible through other means. It's nice that we can do
this much without additional RPCs but it leaves the 'artifact' that
the shared memory data store (the file) is accessible through the
filesystem and potentially removable through an over-zealous /tmp
cleaner. I can think of nothing in any specification which says
that SHM cannot be implemented in this way, but it's the only
with this feature that I know of.
> By the way, please do not feel bad that I rewrote your patch. I am
> sure that once Roland takes some time to look at my proposal, he will
> make it equally unrecognizable.
No offense taken. I'm just glad I was able to start the process
and bootstrap some work on it.
--
Jonathan S. Arney
Software Engineer
[EMAIL PROTECTED]
------------------------------------------------------------------------
Some people call me a nihilist.
That would be true except I don't believe in nihilism.
------------------------------------------------------------------------
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
