[[!meta copyright="Copyright © 2011, 2012, 2013 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]]."]]"""]] [[!taglink open_issue_documentation]] A bunch of this should also be covered in other (introductionary) material, like Bushnell's Hurd paper. All this should be unfied and streamlined. [[!toc]] # IRC, freenode, #hurd, 2011-03-08 I've a question on what are the "units" in the hurd project, if you were to divide them into units if they aren't, and what are the dependency relations between those units(roughly, nothing too pedantic for now) there is GNU Mach (the microkernel); there are the server libraries in the Hurd package; there are the actual servers in the same; and there is the POSIX implementation layer in glibc relations are a bit tricky Mach is the base layer which implements IPC and memory management hmm I'll probably allocate time for dependency graph generation, in the worst case on top of this, the Hurd servers, using the server libraries, implement various aspects of the system functionality client programs use libc calls to use the servers (servers also use libc to communicate with other servers and/or Mach though) so every server depends solely on mach, and no other server? s/mach/mach and/or libc/ I think these things should be pretty clear one you are somewhat familiar with the Hurd architecture... nothing really tricky there no servers often depend on other servers for certain functionality # IRC, freenode, #hurd, 2011-03-12 when mach first starts up, does it have some basic i/o or fs functionality built into it to start up the initial hurd translators? I/O is presently completely in Mach filesystems are in userspace the root filesystem and exec server are loaded by grub o I see so in order to start hurd, you would have to start mach and simultaneously start the root filesystem and exec server? not exactly GRUB loads all three, and then starts Mach. Mach in turn starts the servers according to the multiboot information passed from GRUB ok, so does GRUB load them into ram? I'm trying to figure out in my mind how hurd is initially started up from a low-level pov yes, as I said, GRUB loads them ok, thanks antrik...I'm new to the idea of microkernels, but a veteran of monolithic kernels although I just learned that windows nt is a hybrid kernel which I never knew! note there's a /hurd/ext2fs.static I belive that's what is used initially... right? yes loading the shared libraries in addition to the actual server would be unweildy so the root FS server is linked statically instead what does the root FS server do? well, it serves the root FS ;-) it also does some bootstrapping work during startup, to bring the rest of the system up # Source Code Documentation Provide a cross-linked sources documentation, including generated files, like RPC stubs. * # [[Hurd_101]] # [[hurd/IO_path]] Need more stuff like that. # IRC, freenode, #hurd, 2011-10-18 what happens @ boot. and which translators are started in what order? short version: grub loads mach, ext2, and ld.so/exec; mach starts ext2; ext2 starts exec; ext2 execs a few other servers; ext2 execs init. from there on, it's just standard UNIX stuff # IRC, OFTC, #debian-hurd, 2011-11-02 is __dir_lookup a RPC ?? where can i find the source of __dir_lookup ?? grepping most gives out rvalue assignments -assignments but in hurs/fs.h it is used as a function ?? it should be the mig-generated function for that rpc how do i know how its implemented ?? is there any way to delve deeprer into mig-generated functions sekon_: The MIG-generated stuff will either be found in the package's build directory (if it's building it for themselves), or in the glibc build directory (libhurduser, libmachuser; which are all the available user RPC stubs). sekon_: The implementation can be found in the various Hurd servers/libraries. sekon_: For example, [hurd]/libdiskfs/dir-lookup.c. sekon_: What MIG does is provide a function call interface for these ``functions'', and the Mach microkernel then dispatches the invocation to the corresponding server, for example a /hurd/ext2fs file system (via libdiskfs). sekon_: This may help a bit: http://www.gnu.org/software/hurd/hurd/hurd_hacking_guide.html # IRC, freenode, #hurd, 2012-01-08 can you tell me how is done in hurd: "ls | grep x" ? in bash ls's standard output is a port to the pflocal server, and grep x's standard input is a port to the pflocal server the connexion between both ports inside the pflocal server being done by bash when it calls pipe() youpi, so STDOUT_FILENO, STDIN_FILENO, STDERR_FILENO still exists ? sure, hurd is compatible with posix so bash 1) creates T1 (ls) and T2 (grep), then create a pipe at the pflocal server, then connects both ends to T1 and T2, then start(T1), start(T2) ? not exactly it's like on usual unix, bash creates the pipe before creating the tasks then forks to create both of them, handling them each side of the pipe ok I see s/handling/handing/ but when you do pipe() on linux, it creates a kernel object, this time it's 2 port on the pflocal ? yes how are spawned tasks ? with fork() ? yes which is just task_create() and duplicating the ports into the new task ok so it's easy to rewrite fork() with a good control of duplicated fd about threading, mutexes, conditions, etc.. are kernel objects or just userland objects ? just ports (only threads are kernel objects) so, about efficiency, are pipes and mutexes efficient ? depends what you call "efficient" it's less efficient than on linux, for sure but enough for a workable system maybe hurd is the right place for a userland thread library like pth or any fiber library ? hurd already uses a userland thread library libcthreads is it M:N ? libthreads, actually yes Actually, the Hurd has never used an M:N model. Both libthreads (cthreads) and libpthread use an 1:1 model. nice is the task scheduler in the kernel ? the kernel thread scheduler, yes, of course there has to be one are the posix open()/readdir()/etc... the direct vfs or wraps an hurd layer libvfs ? they wrap RPCs to the filesystem servers the Bushnell paper is probably the closest we have to a high-level documentation of these concepts... the Hurd does not have a central VFS component at all. name lookups are performed directly on the individual FS servers that's probably the most fundamental design feature of the Hurd (all filesystem operations actually, not only lookups) ## IRC, freenode, #hurd, 2012-01-09 youpi: are you sure cthreads are M:N ? i'm almost sure they're 1:1 and no modern OS is a right place for any thread userspace library, as they wouldn't have support to run threads on different processors (unless processors can be handled by userspace servers, but still, it requires intimate cooperation between the threading library and the kernel/userspace server in any case braunr: in libthreads, they are M:N you can run threads on different processors by using several kernel threads, there's no problem in there, a lot of projects do this a pure userspace library can't use kernel threads at least pth was explacitely used on systems like bsd at a time when they didn't have kernel threads exactly for that reason explicitely* and i'm actually quite surprised to learn that we have an M:N threading model :/ why do you say "can't" ? but i wanted to reply to abique and he's not around of course you need kernel threads but all you need is to bind them well, what i call a userspace threading library is a library that completely implement threads without the support of the kernel or only limited support, like signals errr, you can't implement anything with absolutely no support of the kernel pth used only SIGALRM iirc asking for more kernel threads to use more processors doesn't seem much it's not but i'm refering to what abique said 01:32 < abique> maybe hurd is the right place for a userland thread library like pth or any fiber library well, it's indeed more, because the glibc lets external libraries provide their mutex while on linux, glibc doesn't i believe he meant removing thread support from the kernel :p ah and replying "nice" to an M:N threading model is also suspicious, since experience seems to show 1:1 models are better "better" ???? yes well I don't have any time to argue about that because that'd be extremely long simpler, so far less bugs, and also less headache concerning posix conformance but there's no absolute "better" here but less performant less flexible that's why i mention experience :) I mean experience too why less performant ? because you pay kernel transition because you don't know anything about the application threads etc. really ? yes i fail to see where the overhead is I'm not saying m:n is generally better than 1:1 either thread switch, thread creation, etc. creation is slower, i agree, but i'm not sure it's used frequently enough to really matter it is sometimes used frequently enough and in those cases it would be a headache to avoid it ok i thought thread pools were used in those cases synchronized with kernel mutexes ? that's still slow it reduces to the thread switch overhead which, i agree is slightly slower ok, i's a bit less performant :) well don't futexes exist just for that too ? yes and no in that case they don't help because they do sleep they help only when the threads are living ok now as I said I don't have to talk much more, I have to leave :) # IRC, freenode, #hurd, 2012-12-06 spiderweb: have you read http://www.gnu.org/software/hurd/hurd-paper.html ? I'll have a look. and also the beginning of http://ftp.sceen.net/mach/mach_a_new_kernel_foundation_for_unix_development.pdf these two should provide a good look at the big picture the hurd attemtps to achieve I can't help but wonder though, what advantages were really achieved with early mach? weren't they just running a monolithic unix server like osx does? most mach-based systems were but thanks to that, they could provide advanced features over other well established unix systems while also being compatible so basically it was just an ease of development thing well that's what mach aimed at being same for the hurd making things easy but as a side effect hurd actually delivers on the advantages of microkernels aside from that, but the older systems wouldn't, correct? that's how there could be network file systems in very short time and very scarce resources (i.e. developers working on it), while on other systems it required a lot more to accomplish that no, it's not a side effect of the microkernel the hurd retains and extends the concept of flexibility introduced by mach the improved stability, etc. isn't a side effect of being able to restart generally thought of as system-critical processes? no you can't restart system critical processes on the hurd either that's one feature of minix, and they worked hard on it ah, okay. so that's currently just the domain of minix okay spiderweb: well, there's 1 advantage of minix for you :P the main idea of mach is to make it easy to extend unix without having hundreds of system calls the hurd keeps that and extends it by making many operations unprivileged you don't need special code for kernel modules any more it's easy you don't need special code to handle suid bits and other ugly similar hacks, it's easy you don't need fuse easy etc.. # Service Directory ## IRC, freenode, #hurd, 2012-12-06 what is the #1 feature that distinguished hurd from other operating systems. the concept of translators. (will read more when I get more time). yes, translators using the VFS as a service directory and the VFS permissions to control access to those services ## IRC, freenode, #hurd, 2013-05-23 Hi, is there any efficient way to control which backed translators are called via RPC with a user space program? Take for example io_stat: S_io_stat is defined in boot/boot.c, pfinet/io-ops.c and pflocal/io.c 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 How are they related? gnu_srs: it depends on the server (translator) managing the files (nodes) you're accessing so use fsysopts to know the server, and see what this server uses fsysopts /hurd/pfinet and fsysopts /hurd/pflocal gives the same answer: ext2fs --writable --no-inherit-dir-group --store-type=typed device:hd0s1 of course the binaries are regular files see /servers/socket/1 and /servers/socket/2 instead which are the nodes representing the *service* again, the hurd uses the file system as a service directory this usage of the file system is at the core of the hurd design files are not mere files, they're service names it happens that, for most files, the service behind them is the same as for regular files gnu_srs: this *must* be obvious for you to do any tricky work on the hurd Anyway, if I create a test program calling io_stat I assume S_io_stat in pflocal is called. How to make the program call S_io_stat in pfinet instead? create a socket managed by pfinet i.e. an inet or inet6 socket you can't assume io_stat is serviced by pflocal only stats on unix sockets of pipes will be or* thanks, what about the *_S_io_stat functions? what about them ? How they fit into the picture, e.g. diskfs_io_stat? *diskfs_S_io_stat gnu_srs: if you open a file managed by a server using libdiskfs, e.g. ext2fs, that one will be called Using the same user space call: io_stat, right? it's all userspace say rather, client-side 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 the io_stat can change depending on the server the remote io_stat implementation, i mean identify the server, and you will identify the actual implementation ## IRC, freenode, #hurd, 2013-06-30 hi, what is the replacer of netname_check_in? I want to ask another question. in my opinion, the rpc is the mach's way, and the translator is the hurd's way. so somebody want to lookup a service, it should not need to ask the mach kernel know about this query. the hurd will take the control. am I right? no that's nonsense service lookups has never been in mach first mach based systems used a service directory, whereas the hurd uses the file system for that you still need mach to communicate with either of those how to understand the term of service directory here? a server everyone knows which gives references to other servers usually, depending on the name e.g. name_lookup("net") -> port right to network server is that people use netname_check_in to register service in the past? now used libtrivfs? i don't know about netname_check_in old mach (not gnumach) documentation might mention this service directory libtrivfs doesn't have much to do with that on the hurd, the equivalent is the file system maybe that is outdate, I just found that exist old doc, and old code which can't be build. every process knows / the file system is the service directory nodes refer to services so the file system is the nameserver, any new service should register in it before other can use and the file system is distributed, so looking up a service may require several queries setting a translator is exactly that, registering a program to service requests on a node the file system isn't one server though programs all know about /, but then, lookups are recursive e.g. if you have / and /home, and are looking for /home/hacklu/.profile, you ask / which tells you about /home, and /home will give you a right to /home/hacklu/.profile even in the past, the mach don't provide name register service, there must be an other server to provide this service? yes what's nonsense in your sentence is comparing RPCs and translators translators are merely servers attached to the file system, using RPCs to communicate with the rest of the system I know yet, the two just one thing. no two things :p completely different and unrelated except for one using the other ah, just one used aonther one. is exist anyway to anounce service except settrans with file node? more or less tasks can have special ports that's how one task knows about / for example at task creation, a right to / is inserted in the new task I think this is also a file node way. no if i'm right, auth is referenced the same way and there is no node for auth how the user get the port of auth with node? it's given when a task is created pre-set in the creation of one task? i'm unconfortable with "pre-set" inserted at creation time auth is started very early then tasks are given a reference to it # IRC, freenode, #hurd, 2012-12-10 I want to work on hurd, but I think I'm going to start with minix, I own the minix book 3rd ed. it seems like a good intro to operating systems in general. like I don't even know what a semaphore is yet. well, enjoy learning :) once I finish that book, what reading do you guys recommend? other than the wiki i wouldn't recommend starting with a book that focuses on one operating system anyway you tend to think in terms of what is done in that specific implementation and compare everything else to that tannenbaum is not only the main author or minix, but also the one of the book http://en.wikipedia.org/wiki/Modern_Operating_Systems http://en.wikipedia.org/wiki/List_of_important_publications_in_computer_science#Operating_systems should be a pretty good list :) # IRC, freenode, #hurd, 2013-03-12 i have a question regarding ipc in hurd. if a task is created, does it contain any default port rights in its space? i am trying to deduce how one calls dir_lookup() on the root translator in glibc's open(). mjjc: yes, there are some default port rights, but I don't remember the details :/ kilobug: do you know where i should search for details? mjjc: hum either in the Hurd's hacking guide https://www.gnu.org/software/hurd/hacking-guide/ or directly in the source code of exec server/libc I would say, or just ask again the question here later on to see if someone else has more information ok, thanks there's also rpctrace to, as the name says, trace all the rpc's executed some ports are introduced in new tasks, yes see http://www.gnu.org/software/hurd/hacking-guide/hhg.html#The-main-function and http://www.gnu.org/software/hurd/gnumach-doc/Task-Special-Ports.html#Task-Special-Ports yes, the second link was just what i was looking for, thanks the second is very general also, the first applies to translators only if you're looking for how to do it for a non-translator application, the answer is probably somewhere in glibc _hurd_startup i'd guess # IRC, freenode, #hurd, 2013-06-15 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... yes but not really that way under the current hurd model of the operating system, how would you talk to hardware that required specific timings like sound hardware? through mapped memory is there such a thing as an interrupt request in hurd? obviously ok is there any documentation i can read that involves a driver that uses irqs for hurd? you can read the netdde code dde being another project, there may be documentation about it somewhere else i don't know where thanks 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 yes it must translate these system calls into ipc or something then mach handles it? exactly that's why i say it's not the exokernel way of doing things ok so does every low level hardware access go through mach?' yes well no interrupts do ports (on x86) everything else should be doable through mapped memory seems surprising that the code for it is so small 1/ why surprising ? and 2/ "so small" ? its like the core of the OS, and yet its tiny compared to say the linux kernel it's a microkenrel well, rather an hybrid the size of the equivalent code in linux is about the same ok 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 privileged instructions remain in the kernel that's one of the few responsibilities of the kernel i see, so it is an illusion that the user has privilege in a sense hum no or, define "illusion" well the user can suddenly do things never imaginable in linux that would have required sudo yes well, they're not unimaginable on linux it's just not how it's meant to work :) and why things like fuse are so slow i still don't get "i see, so it is an illusion that the user has privilege in a sense" because the user doesnt actually have the elevated privilege its the server thing (translator)? it does not at the hardware level, but at the system level not being able to do it directly doesn't mean you can't do it right it means you need indirections that's what the kernel provides so the user cant do stuff like outb 0x13, 0x1 he can he also can on linux oh that's an x86 specifity though but the user would need hardware privilege to do that no or some kind of privilege there is a permission bitmap in the TSS that allows userspace to directly access some ports but that's really x86 specific, again i was using it as an example i mean you wouldnt want userspace to directly access everything yes the only problem with that is dma reall y because dma usually access physical memory directly are you saying its good to let userspace access everything minus dma? otherwise you can just centralize permissions in one place (the kernel or an I/O server for example) no you don't let userspace access everything ah yes userspace asks for permission to access one specific part (a memory range through mapping) and can't access the rest (except through dma) except through dma?? doesnt that pose a large security threat? no you don't give away dma access to anyone only drivers ahh and drivers are normally privileged applications anyway so a driver runs in userspace? so the only effect is that bugs can affect other address spaces indirectly netdde does interesting and they all should but that's not the case for historical reasons i want to port ALSA to hurd userspace :D that's not so simple unfortunately one of the reasons it's hard is that pci access needs arbitration and we don't have that yet i imagine that would be difficult yes