Re: reiser4 plugins

[Ross Biro]

On 6/29/05, Hubert Chan [EMAIL PROTECTED] wrote:
 On Wed, 29 Jun 2005 01:09:05 -0400, Horst von Brand [EMAIL PROTECTED] said:
 
  Hubert Chan [EMAIL PROTECTED] wrote: [...]
  And doing tar cf /dev/tape /usr/games/tetris gives you a nice tangle
  of undecipherable junk.
 

I'm confused.  Can someone on one of these lists enlighten me?

How is directories as files logically any different than putting all
data into .data files and making all files directories (yes you would
need some sort of special handling for files that were really called
.data).  Then it's just a matter of deciding what happens when you
call open and stat on one of these files?

For backwards compatibility, current existing system calls have to
treat these things as directories.  Perhaps an exception could be made
for exec.

But we could have a whole new set of system calls that treat things as
magic, and if files as directories is as cool as many people think,
apps will start using the new api.  If not, they won't and the new api
can be deprecated.

Ross

Re: -mm - 2.6.13 merge status

[Ross Biro]

On 6/23/05, Olivier Galibert [EMAIL PROTECTED] wrote:

 No, I think he means the traditional:
 
 reiser4_fill_super()
 {
if (init_a())
  goto failed_a;
.
.
.

IMO this works very well when the initialization always completes or
fails totally in a single routine.  When your init routine can leave
something partially inited, then putting all of the cleanup code in a
single function and using the enums eliminates duplicate code and
makes things easier to read.  (it's a state machine like many device
drivers and network stacks).

Also, perhaps a compromise on the asserts at the beggining of
functions.  If they are moved into a header file, say
resier4_contracts.h and replaced with a single macro, you get most of
the benefits and elminate most of the clutter.  If properly done,
there may even be some advantages gained by auto generating the
conttact.h file(s) from some sort of formal spec or design doc.

Ross