libstore is used to provide a generic interface to access data (read/write)
on backing stores.
It more than just a thin layer between GNU Mach
hd0 for example) and the device node below
- bunzip2 store: bunzip2 data on the fly
- concat store: concatenate
- copy store: copy-on-write; discard changes on termination
- device store: Mach device access
- file store: use a file as a kind of block device
- gunzip store: gunzip data on the fly
- ileave store: interleave store (striping)
- nbd store: Linux-compatible network block device
- query store
- remap store
- task store: Mach task store backend
- typed store: chainable stores
- url store: typed store with URL syntax
- zero store: empty block device
At http://www.kataplop.net/pub/info/projets you can find some effort to make some crypto store.
At http://www.trek.eu.org/devel/hurd/crypt-trans-0.0.3.tgz, another package can be found.
$ settrans --create --active ramdisk0 /hurd/storeio -T copy zero:32M $ mkfs.ext2 -F -b 4096 ramdisk0 [...] $ settrans --active --orphan ramdisk0 /hurd/ext2fs.static ramdisk0 $ df -h ramdisk0/ df: Warning: cannot read table of mounted file systems Filesystem Size Used Avail Use% Mounted on - 32M 1.1M 30M 4% /media/data/home/tschwinge/ramdisk0
This uses settrans and to create a ramdisk of 32 MiB by routing
a thusly sized zero store through the copy store, connecting
that to the
ramdisk0 node, create a
ext2 filesystem on it, and replace the
translator running on the
ramdisk0 node with a instance of the
translator running on the same node ( ).
It is a open issue hurd why this does only work with
ext2fs.static, but not the dynamically linked
/hurd/ext2fs: Translator died).
A (better) alternative would be using the
translator, but that one is broken at the moment.
<teythoon> and I read hammys paper about mobile code, is it true that the store code is loaded into the client? who is the server and who is the client in this context? <braunr> teythoon: "store code" ? <teythoon> libstore <braunr> the hurd libstore ? <teythoon> yes <braunr> hum, what paper ? <teythoon> braunr: http://users.student.lth.se/cs07fh9/2009-hammar-hurd-mobility.pdf <braunr> how nice <tschwinge> braunr: http://www.gnu.org/software/hurd/news/2010-01-31.html <teythoon> it raises an important point btw, the authentication done by processes on the Hurd is one sided, only the client authenticates at the server <braunr> yes <tschwinge> It'S also mentioned in http://www.gnu.org/software/hurd/hurd/documentation.html -- but of course, any results he got from his work really should be integrated more properly into the existing body of documents. <tschwinge> As with so many other documents/discussions/etc. ;-|