Re: silent semantic changes with reiser4

[Spam]

> Spam <spam@xxxxxxxxxxxx> wrote:
>>
>> 
>> 
>> > Spam <spam@xxxxxxxxxxxx> wrote:
>> >>
>> >>    Yes,  for  example  documents,  image  files  etc. The multiple data
>> >>    streams  can  contain thumbnails, info about who is editing the file
>> >>    (useful for networked files) etc. Could be used for version handling
>> >>    and much more.
>> 
>> > All of which can be handled in userspace library code.
>> 
>> > What compelling reason is there for doing this in the kernel?
>> 
>> 
>>   Because  having user space tools and code will make it not work with
>>   everything. Keeping stuff in the kernel should make the new features
>>   transparent to the applications.
>> 
>>   Applications  that support the new features will benefit, all others
>>   will continue to work without destroying data.

> Sorry, but that all sounds a bit fluffy.   Please provide some examples.

  We  already had the examples with cp and mv. Both should continue to
  work and the files will still be copied. The same with Konqueror and
  Nautilus.  Files  and  their  meta-files/streams/attributes  will be
  retained as long as applications are using the OS API.

  However,  if  things  are  to  implemented  in  user-space, then old
  applications  will not work correctly and there is risk that all the
  extra information will be lost or corrupted.

  You  said  it  would be socially hard. I think it would be very much
  close to impossible to get it right. Imagine that Gnome and Nautilus
  would  implement  support  for  these. I doubt that cp, mv, KDE, mc,
  app-xyz  would  implement  this anytime soon and in the meantime the
  data is at risk.

  If  we  want  things  to  work  from  the  start, including with old
  applications  then  these  features  should  be at below-application
  level.  If  it  is  in VFS or FS doesn't matter to me, as long as it
  doesn't hinder or delay progress to long.

> (Generally, getting all of userspace to agree on a particular library is
> socially hard [*], but I don't see that as a reason for putting the
> functionality into the kernel)

> [*] Example: where's the library to manipulate /etc/whatever.conf? [**]

> [**] yes, I know about gconf.




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/