bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

libstore "unknown" type


From: Roland McGrath
Subject: libstore "unknown" type
Date: Fri, 28 Dec 2001 19:49:34 -0500 (EST)

I have added a new store type called "unknown" (libstore/unknown.c).  This
is a special type to represent a file_get_storage_info result that does not
appear to be any type libstore knows about.  The only way stores of this
type can be created is by decoding, you cannot open one by name.

When store_create gets (and hence store_open and store_parsed_open)
file_get_storage_info results it can't understand, it fails with EINVAL.  I
changed store_create so that when given the STORE_NO_FILEIO flag, it will
instead create a store of type "unknown".  

On an "unknown" store, all the io calls just fail (with EFTYPE).  But
store_encode on the store will produce exactly the data that was given to
store_unknown_decode to create the store.  The name reported for the store
is synthesized from some of the file_get_storage_info data so you can guess
what format it might be in.

I've changed the storeinfo utility to use STORE_NO_FILEIO in its
store_create calls, so storeinfo on a file whose file_get_storage_info data
is unrecognizable ought to show you the store name synthesized from the data.

Conveniently you can test this because I added support for the
file_get_storage_info RPC to the nfs client filesystem, but there is no
corresponding store type.  If all of this works, storeinfo on an NFS file
should show you some kind of URL with the NFS file handle data in it.


I added a --no-file-io flag to the /hurd/storeio translator, which makes it
pass STORE_NO_FILEIO in its store_parsed_open calls.  That is, storeio will
refuse to fall back to plain file io calls to the target file when using
the file type.  So e.g. after:

        settrans -ca /tmp/foo /hurd/storeio --no-file-io /foo/bar

if /foo/bar is a file that implements file_get_storage_info but returns an
unrecognized result, io on /tmp/foo will fail.  However, storeinfo /tmp/foo
should display the same info as storeinfo /foo/bar.


These changes all build ok and I don't think they should much affect
existing code.  But I haven't tested any of it, of course.  Please test
this stuff for me if you can.  Specifically, I would love to see storeinfo
actually output something understandable for an NFS file.



Thanks,
Roland



reply via email to

[Prev in Thread] Current Thread [Next in Thread]