From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dave <dave@dave.tj>
Subject: Re: [9fans] blanks in file names
In-reply-to: <20020707060502.639E6199B9@mail.cse.psu.edu> from
 <"arisawa@ar.aichi-u.ac.jp"@Jul>
To: 9fans@cse.psu.edu
Message-id: <200207071611.g67GBgP18236@dave2.dave.tj>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Date: Sun,  7 Jul 2002 12:11:41 -0400
Topicbox-Message-UUID: c42f4e9a-eaca-11e9-9e20-41e7f4b1d025

The idea behind our new open(2) is to create a cleaner representation
for paths.  If we want, we can patch the old open(2) - which could
become a library function open2(3) - to support one or more of the
userland naming conventions we were discussing.  However, I don't think
the kernel should meddle with userland naming conventions; having the
kernel deal with binary data in linked lists is by far the cleanest
approach proposed thus far, IMHO.  It also opens the door to all sorts
of neat possibilities for path manipulation without string manipulation.
Finally, it gives us the capability of getting away from even the most
elementary requirements in a filesystem (like inodes) at some point in
the future without extensive code changes.  Basically, it's all about
flexibility, a long-time strength of the UNIX system which has only been
improved upon in Plan 9.

 - Dave


arisawa@ar.aichi-u.ac.jp wrote:
> 
> Another escape may be a % of that is used in URI.
> 
> %	->	%25
> /	->	%2f
> space	->	%20
> 
> and if open can accept these, new_open is not reqired.
> 
> Kenji Arisawa
>