diff options
Diffstat (limited to 'open_issues/anatomy_of_a_hurd_system.mdwn')
| -rw-r--r-- | open_issues/anatomy_of_a_hurd_system.mdwn | 217 |
1 files changed, 217 insertions, 0 deletions
diff --git a/open_issues/anatomy_of_a_hurd_system.mdwn b/open_issues/anatomy_of_a_hurd_system.mdwn index 677e4625..11a1f754 100644 --- a/open_issues/anatomy_of_a_hurd_system.mdwn +++ b/open_issues/anatomy_of_a_hurd_system.mdwn @@ -380,3 +380,220 @@ Actually, the Hurd has never used an M:N model. Both libthreads (cthreads) and l <braunr> if you're looking for how to do it for a non-translator application, the answer is probably somewhere in glibc <braunr> _hurd_startup i'd guess + + +# IRC, freenode, #hurd, 2013-05-23 + + <gnu_srs> Hi, is there any efficient way to control which backed + translators are called via RPC with a user space program? + <gnu_srs> Take for example io_stat: S_io_stat is defined in boot/boot.c, + pfinet/io-ops.c and pflocal/io.c + <gnu_srs> And the we have libdiskfs/io-stat.c:diskfs_S_io_stat, + libnetfs/io-stat.c:netfs_S_io_stat, libtreefs/s-io.c:treefs_S_io_stat, + libtrivfs/io-stat.c:trivfs_S_io_stat + <gnu_srs> How are they related? + <braunr> gnu_srs: it depends on the server (translator) managing the files + (nodes) you're accessing + <braunr> so use fsysopts to know the server, and see what this server uses + <gnu_srs> fsysopts /hurd/pfinet and fsysopts /hurd/pflocal gives the same + answer: ext2fs --writable --no-inherit-dir-group --store-type=typed + device:hd0s1 + <braunr> of course + <braunr> the binaries are regular files + <braunr> see /servers/socket/1 and /servers/socket/2 instead + <braunr> which are the nodes representing the *service* + <braunr> again, the hurd uses the file system as a service directory + <braunr> this usage of the file system is at the core of the hurd design + <braunr> files are not mere files, they're service names + <braunr> it happens that, for most files, the service behind them is the + same as for regular files + <braunr> gnu_srs: this *must* be obvious for you to do any tricky work on + the hurd + <gnu_srs> fsysopts /servers/socket/2 works by /1 gives Operation not + supported. + +[[!taglink open_issue_hurd]]. + + <braunr> ah right, some servers don't implement that + <braunr> work around this by using showtrans + <braunr> fsysopts asks the server itself how it's running, usually giving + its command name and options + <braunr> showtrans asks the parent how it starts a passive translator + attached to the node + <gnu_srs> Yes showtrans works :), thanks. + <gnu_srs> Anyway, if I create a test program calling io_stat I assume + S_io_stat in pflocal is called. + <gnu_srs> How to make the program call S_io_stat in pfinet instead? + <braunr> create a socket managed by pfinet + <braunr> i.e. an inet or inet6 socket + <braunr> you can't assume io_stat is serviced by pflocal + <braunr> only stats on unix sockets of pipes will be + <braunr> or* + <gnu_srs> thanks, what about the *_S_io_stat functions? + <braunr> what about them ? + <gnu_srs> How they fit into the picture, e.g. diskfs_io_stat? + <gnu_srs> *diskfs_S_io_stat + <braunr> gnu_srs: if you open a file managed by a server using libdiskfs, + e.g. ext2fs, that one will be called + <gnu_srs> Using the same user space call: io_stat, right? + <braunr> it's all userspace + <braunr> say rather, client-side + <braunr> the client calls the posix stat() function, which is implemented + by glibc, which converts it into a call to io_stat, and sends it to the + server managing the open file + <braunr> the io_stat can change depending on the server + <braunr> the remote io_stat implementation, i mean + <braunr> identify the server, and you will identify the actual + implementation + + +# IRC, freenode, #hurd, 2013-06-15 + + <damo22> ive been reading a little about exokernels or unikernels, and i + was wondering if it might be relevant to the GNU/hurd design. I'm not + too familiar with hurd terminology so forgive me. what if every + privileged service was compiled as its own mini "kernel" that handled (a) + any hardware related to that service (b) any device nodes exposed by that + service etc... + <braunr> yes but not really that way + <damo22> under the current hurd model of the operating system, how would + you talk to hardware that required specific timings like sound hardware? + <braunr> through mapped memory + <damo22> is there such a thing as an interrupt request in hurd? + <braunr> obviously + <damo22> ok + <damo22> is there any documentation i can read that involves a driver that + uses irqs for hurd? + <braunr> you can read the netdde code + <braunr> dde being another project, there may be documentation about it + <braunr> somewhere else + <braunr> i don't know where + <damo22> thanks + <damo22> i read a little about dde, apparently it reuses existing code from + linux or bsd by reimplementing parts of the old kernel like an api or + something + <braunr> yes + <damo22> it must translate these system calls into ipc or something + <damo22> then mach handles it? + <braunr> exactly + <braunr> that's why i say it's not the exokernel way of doing things + <damo22> ok + <damo22> so does every low level hardware access go through mach?' + <braunr> yes + <braunr> well no + <braunr> interrupts do + <braunr> ports (on x86) + <braunr> everything else should be doable through mapped memory + <damo22> seems surprising that the code for it is so small + <braunr> 1/ why surprising ? and 2/ "so small" ? + <damo22> its like the core of the OS, and yet its tiny compared to say the + linux kernel + <braunr> it's a microkenrel + <braunr> well, rather an hybrid + <braunr> the size of the equivalent code in linux is about the same + <damo22> ok + <damo22> with the model that privileged instructions get moved to + userspace, how does one draw the line between what is OS and what is user + code + <braunr> privileged instructions remain in the kernel + <braunr> that's one of the few responsibilities of the kernel + <damo22> i see, so it is an illusion that the user has privilege in a sense + <braunr> hum no + <braunr> or, define "illusion" + <damo22> well the user can suddenly do things never imaginable in linux + <damo22> that would have required sudo + <braunr> yes + <braunr> well, they're not unimaginable on linux + <braunr> it's just not how it's meant to work + <damo22> :) + <braunr> and why things like fuse are so slow + <braunr> i still don't get "i see, so it is an illusion that the user has + privilege in a sense" + <damo22> because the user doesnt actually have the elevated privilege its + the server thing (translator)? + <braunr> it does + <braunr> not at the hardware level, but at the system level + <braunr> not being able to do it directly doesn't mean you can't do it + <damo22> right + <braunr> it means you need indirections + <braunr> that's what the kernel provides + <damo22> so the user cant do stuff like outb 0x13, 0x1 + <braunr> he can + <braunr> he also can on linux + <damo22> oh + <braunr> that's an x86 specifity though + <damo22> but the user would need hardware privilege to do that + <braunr> no + <damo22> or some kind of privilege + <braunr> there is a permission bitmap in the TSS that allows userspace to + directly access some ports + <braunr> but that's really x86 specific, again + <damo22> i was using it as an example + <damo22> i mean you wouldnt want userspace to directly access everything + <braunr> yes + <braunr> the only problem with that is dma reall + <braunr> y + <braunr> because dma usually access physical memory directly + <damo22> are you saying its good to let userspace access everything minus + dma? + <braunr> otherwise you can just centralize permissions in one place (the + kernel or an I/O server for example) + <braunr> no + <braunr> you don't let userspace access everything + <damo22> ah + <damo22> yes + <braunr> userspace asks for permission to access one specific part (a + memory range through mapping) + <braunr> and can't access the rest (except through dma) + <damo22> except through dma?? doesnt that pose a large security threat? + <braunr> no + <braunr> you don't give away dma access to anyone + <braunr> only drivers + <damo22> ahh + <braunr> and drivers are normally privileged applications anyway + <damo22> so a driver runs in userspace? + <braunr> so the only effect is that bugs can affect other address spaces + indirectly + <braunr> netdde does + <damo22> interesting + <braunr> and they all should but that's not the case for historical reasons + <damo22> i want to port ALSA to hurd userspace :D + <braunr> that's not so simple unfortunately + <braunr> one of the reasons it's hard is that pci access needs arbitration + <braunr> and we don't have that yet + <damo22> i imagine that would be difficult + <braunr> yes + <braunr> also we're not sure we want alsa + <braunr> alsa drivers, maybe, but probably not the interface itself + <damo22> its tangled spaghetti + <damo22> but the guy who wrote JACK for audio hates OSS, and believes it is + rubbish due to the fact it tries to read and write to a pcm device node + like a filesystem with no care for timing + <braunr> i don't know audio well enough to tell you anything about that + <braunr> was that about oss3 or oss4 ? + <braunr> also, the hurd isn't a real time system + <braunr> so we don't really care about timings + <braunr> but with "good enough" latencies, it shouldn't be a problem + <damo22> but if the audio doesnt reach the sound card in time, you will get + a crackle or a pop or a pause in the signal + <braunr> yep + <braunr> it happens on linux too when the system gets some load + <damo22> some users find this unnacceptable + <braunr> some users want real time systems + <braunr> using soft real time is usually plenty enough to "solve" this kind + of problems + <damo22> will hurd ever be a real time system? + <braunr> no idea + <youpi> if somebody works on it why not + <youpi> it's the same as linux + <braunr> it should certainly be simpler than on linux though + <damo22> hmm + <braunr> microkernels are well suited for real time because of the well + defined interfaces they provide and the small amount of code running in + kernel + <damo22> that sounds promising + <braunr> you usually need to add priority inheritance and take care of just + a few corner cases and that's all + <braunr> but as youpi said, it still requires work + <braunr> and nobody's working on it + <braunr> you may want to check l4 fiasco.oc though |