1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
|
[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]]
[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
is included in the section entitled
[[GNU_Free_Documentation_License|/fdl]]."]]"""]]
A translator is simply a normal program acting as
an object server and participating in the Hurd's
distributed [[virtual_file_system]]. It is so-called
because it typically exports a file system
(although need not: cf. [[auth]], [[proc]]
and [[pfinet]]) and thus translates object invocations
into calls appropriate for the backing store
(e.g., ext2 file system, nfs server, etc.).
A translator is usually registered with a specific file system node by using
the [[`settrans`|settrans]] command.
Translators do not require any special privilege
to run. The privilege they require is simply
that to access the indiviudal resources they use.
This is primarily the [[backing_store]] and the node
they attach to. Typically, a translator can
only be attached to a node by the node's owner.
On Unix this is not possible because file systems
and the virtual file system are implemented in the
kernel and thus have absolute access to the machine.
As the protocols do not require any special privilege
to implement, this is not an issue on the Hurd.
To learn how to write a translator, read the code!
It is well documented, in particular, the header files.
The [[Hurd_Hacking_Guide]] also has a tutorial.
Also there is an [[writing/example]] about how to write a simple translator.
See some [[examples]] about how to use translators.
# Existing Translators
* [[pfinet]]
* [[pflocal]]
* [[hostmux]]
* [[storeio]]
* [[ext2fs]]
* [[fatfs]]
* [[magic]]
* [[mboxfs]]
* [[unionfs]]
* [[xmlfs]]
* ...
# Translators Being Under Development
* [[random]]
* [[emailfs]] -- email as a filesystem
* [[cvsfs]]
* [[tmpfs]]
* [[procfs]]
* ...
# Translator wishlist
* FUSE(fuse.sourceforge.net/) compatilbility library. : just modify FUSE apps a and compile little to work as translator :-)
* File Finder. (uses find, grep, a combination or a custom command (htdig, mp3 info)
* Files found will be available under one directory and then can be used like a normal directory
* usefull to generate Albums, Share only resulting files over the et, etc..
* The filefinder can be scheduled or can be connected over some ipc like dbus to the VFS system if any to keep a watch for new files.
* GNOKII, BitPim and openobex as translators
* grep through your SMSs!
* share your addressbook!
* "Attach" that funny SMS/MMS to your email.
* "svn commit" your joke collection :-D
* Real Language Translator [[br]]
* cat /usr/translator/de-en/usr/share/doc/something.txt should take /usr/share/doc/something.txt , submit it to google's website and bring back results.
* Mozilla Bookmarks = del.ici.ous
* Need more explanation ? ;-)
* <http://hnb.sf.net>
* having a directory structure for a file can allow to "svn commit" the hnb document in a more "node-safe" manner, thus allowing multiple people to work on the same hnb document.
* This must be fairly easy as HNB can already export to XML and XMLfs already exists.
* DavFS
* Just setup a 'WebDav share' as a directory. The implimentation of the protocol is already available in nautilus and konqueror.
* Compiled form of your project
* you have your project in /somedir/project with source in /somedir/project/src .. /somedir/project/bin should always have the compiled version.. is it possible?
* The source has to have a MakeFile.
* creating /somedir/project/bin-somearch should aotomatically crosscompile
* Seems feasible for a small project.
* Report generation FrameWork - an idea to be hugged by app developers..not kernel developers.
* You have financial data in some Spreadsheet like format in /yourFinance directory
* You add report templates to /yourFinance/repTemplates
* Once you save data in /yourFinance the next cat /yourFinance/reports/areportname will give you an uptodate report.
* This will be usefull for any purpose including serving by static page web servers, sharing over samba/nfs/ftp etc.!
* The advantage is any save to the spreadsheet will update the report.. not just from one software.
* SVN (Subversion suite)
* like [[cvsfs]]. /svndir/version/version-no should automatically have subversion
* I think it is nice to write a generalised version control system framework library which will help in writing version control translators and other tools easily.
* Flexi-acls
* First of all - Can this be done? : A translator bound to a directory must be able to access the contents of the directory which would have been accessible in the absence of the translator..
* This will enable to wirte translators that can implement custom "Access Control Lists". Just imagine having advanced ACLs even if underlying FileSystem is dumb! Imagine changing the type of ACLs implemented with Just two commands - one to unattach previous translator and the next to attach a different ACL translator! The ACLs themselves may be stored in a different directory
* The translator manager!
* Some translators will need to be inserted automatically - like for eg: hardware drivers ..
* Each hardware translator will pubish its capabilities.
* The "top" translator will query the capabilities of different hardware and match capabilities with the "slave" translators. That is it's only Job.
* The control is then handed over to the slave translator.
* The ranking not only looks who can handle the "most" capabilites of the hardware. If it finds that multiple translators can handle the same hardware, It will use other parameters to choose between them.. like may be the size in memory? The revision date? Stability (inferred from version number)? And to go to the extreme, the profiling data of the driver ;-P
* Advantage : The best driver wins!
* An eg. Skip it if you understood the above :-):
* You have a driver that can handle VGA + SVGA + Super3d acceleration + Particle graphics + Works for nvidea card.
* You have a driver that can handle SVGA + VGA .
* You have a driver that can handle VGA.
* Case 1: Your card: A VGA card with some extra fonts..
* First the VGA driver will be quireied .. ok can handle essential capability.
* Next SVGA driver: can handle but has extra module.. unnecassary weight .
* The Nvidia driver: can handle , but again unnecassary weight : ruled out.
* Winner : VGA driver:
* Case 2: Your card An SVGA card:
* First the VGA driver will be quireied .. ok can handle one essential capability.
* Next SVGA driver: can handle essential and one extra capability no extra weight..
* The Nvidia driver: can handle , but unnecassary weight : ruled out.
* Winner : SVGA driver..
* Case 3 : You have an VGA .. but no VGA driver .. then the SVGA driver would win.
* Sound Server
* /ahsa - stands for Advanced HURD sound architecture :-) Just a temporary name .. for fun.
* /ahsa/out - directory wich will hold "plug"s where apllications come and join the server .. see below.
* /ahsa/out/mixer - main mixer
* /ahsa/out/nextfree - the file when "cat"ed gives the number of the next free plug
* /ahsa/plugins/ - info about available plugins
* /ahsa/out/[1..n]/ - dynamically generated directories for applications to plug on..
* /ahsa/out/[1..n]/data this is where you should do a "cat somerawsoundfile>/ahsa/out/`cat /ahsa/nextfree`/data"
* /ahsa/out/[1..n]/plugins - the plugin stack .. volume is also a plugin..
* /ahsa/out/[1..n]/plugins/[1..m]/ - echo "plugin param1 param2 param3" > /ahsa/out/[1..n]/plugins/`cat /ahsa/out/[1..n]/plugins/nextfree`/add
* /ahsa/out/[1..n]/plugins/[1..m]/params/{param1.. paramn}
* /ahsa/out/[1..n]/data.out - can be catted to get data processed through the server
* /ahsa/in - similar to /ahsa/out .. with except for an extra file to choose input devices.
* /ahsa/devs/{1..n} - devices detected .. can be dynamic .. there are usb soundcards and and midi devices.
* /ahsa/out/[1..n]/plugins/[1..m]/0/params/dev
* Dont get tempted for :/ahsa/out/[1..n]/params/{rate, channels, and other stuff}
* that goes into /ahsa/out/[1..n]/plugins/0/params if /ahsa/out/[1..n]/plugins/0/detected == "headerless audio"
* There are a lot more things I can continue about the "sound server" .. The Ideas simply dont seem to exhaust..
* Some features/advantages
* set output's translator plugin as ordinary text -- have text to speech conversion done by sound server!
* Create and apply plugin presets by simply copying directories!
* Me getting dizzy thinking of the zillion more advantages.
* If you are really doing some ordinary output , all you need to do is "cat" data into next free "plug" and everything will be autodetected including the format of the data and sent to the final sound "merge"r
* Dizzy ...
* /usr/share/menu !!!! extension for package management idea ..
* cat mymenuitem.menu >> /usr/share/menu/menu
* cat /usr/share/menu/debian/kde ... :-)
* Spam/Malware Control
* /usr/antimalware/ - put your mail here.. it will automatically be scanned. when finished it will vanish from here ..
* /usr/antimalware/clean - ... and pop out from here
* /usr/antimalware/malware - or here.
* NetDevice
* !JustImagine(tm)... settrans -ac /netdevices /hurd/netdevfs - [ host | net ]
* One can access device files remotely
* This could be acheived by allowing translators talk to one another over a network
* This will need translators to catch and handle ioctls (if there is such a thing in HURD).
* The device server which will listen to requests from the translators can be run even on a Linux machine!!!
* !JustImagine(tm)... accessing the crwriter/webcam on that GNU/Linux machine on the network using cdrecord of your local hurd machine!
* !JustImagine(tm)... running GNU/HURD on a minimalistic GNU/Linux(but with all the drivers) through a specially modified and optimised Qemu. The device server runs on the host machine, and the client translators access over the virtual network created by Qemu. You got most of the drivers for free!
* Emacs File VFS
* I came to know from my Emacs loving friend that there are lots of VFS handlers in Emacs.. I was wondering if there can be translator which can tap into these Emacs VFS handlers.
|
