Re: GNU From Scratch
El Mon, Dec 26, 2005 at 09:22:00PM +0100, Alfred M. Szmidt ens deleit? amb les seg?ents paraules: > Making a usable system that is easy to upgrade, maintain, and use is far > more work than compiling things from scratch into some directory (which I > can do in about a minute, excluding compilation time). We are currently > working on making the last missing bits of the GNU system fit (package > manager, installer, package build system, etc) so that it is ready to be > used. If you are interested in the GNU system, then you might wish to > read http://www.gnu.org/software/packaging, and subscribe to > [EMAIL PROTECTED] > anyway, there's actually a tool to create a system from scratch on Bee it's called BeeBS (Bee Build Script). It is intended to compile a Hurd system from scratch, and targeted to create a cross compiler (that you can use later) to crosscompile a base system and some basic tools, and performing a final (optional) pass that installs the Bee bootup scripts so yes, you can create a system from scratch, and the script is "easy" to read and understand which steps it performs... (well, at least if you know it ;)) and easily extendable (or at least this was one of its first ideas) so, well, here it is: http://bee.es.gnu.org/ sorry, but the page is in spanish (if I recall well, an english translation is underway), but if you want something, just tell me :) apa! -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth Listening: Nevermore (Dreaming Neon Black) - 09. Poison Godmachine ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: GNU From Scratch
El Mon, Dec 26, 2005 at 10:10:49PM +0100, Alfred M. Szmidt ens deleit? amb les seg?ents paraules: >anyway, there's actually a tool to create a system from scratch on >Bee > > This has already existed for the GNU system since about 1 year now. > sorry, but we didn't know about any working program to build a full GNU/Hurd system from scratch with the ability to crosscompile (that doesn't mean, of course, that it didn't exist before...) we'd be very grateful if you could share a pointer to it with us apa! -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth Listening: Avenged Sevenfold (Waking the Fallen) - 08. Radiant Eclipse ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: Hurdish TCP stack
El Tue, Apr 01, 2008 at 02:55:28PM +0200, Ludovic Courtès ens deleit� amb les seg�ents paraules: > Hi, > > "Joshua Stratton" <[EMAIL PROTECTED]> writes: > >> They use an interesting system to control their connections using ASCII >> strings. For example changing the packet size would be as simple as "2400 >>> ctl" would change the packet size to 2400 (some syntax to that effect). > > Plan 9 does everything through "ctl" files that can be read and written > to with `cat' and `echo', pretty much like Linux sysfs. The downside is > that all commands have to be parsed and interpreted. > > I suppose a more "hurdish" solution would be to use a dedicated RPC > interface (e.g., one with a `set_packet_size ()' RPC) rather than just > use the `io' interface for everything. Hi all, I'm just an sneaker in many lists but... does Hurd support introspection? Or has any plan to support it? In that case there could be an introspection translator for supporting such fs constructs (all by free with a single translator... after paying the cost of implementing introspection, of course :)), but the base code would still be all RPC-based. Just a quick thought through a quick list read. -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth Listening: Joe Satriani (Professor Satchafunkilus and the musterion of rock) - 7. Out of The Sunrise
Re: Hurdish TCP stack
El Wed, Apr 02, 2008 at 09:19:12AM +0200, Ludovic Courtès ens deleit� amb les seg�ents paraules: > Hi, > > Lluis <[EMAIL PROTECTED]> writes: > >> I'm just an sneaker in many lists but... does Hurd support introspection? >> Or has any plan to support it? In that case there could be an introspection >> translator for supporting such fs constructs (all by free with a single >> translator... after paying the cost of implementing introspection, of >> course :)), but the base code would still be all RPC-based. > > `rpctrace' allows one to monitor RPCs made by a program; along with > description files that map message IDs to RPC names, it can provide a > textual representation of the RPCs, à la `strace'. > > Maybe what you propose could be done with a sort-of "rpctracefs" > translator? :-) Well, I don't know how rpctrace internally works, but I suppose it's someting similar to ptrace, which gives information at "use-time", while such a filesystem would need some kind of introspection mechanism on the destination servers, in order to be able to figure out what methods are available, as well as their signature. A quick hack to that could be to store that information in a special section in the ELF (generated by the idl compiler), which simply lists the available RPCs and their signature. Then, setting the translator for a server would be like $ settrans /some/path introspectfs -p /some/server which retrieves the available methods for the server (from the binary's ELF or wherever the information is stored) and exposes them to the fs hierarchy. Read you, Lluis -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth
Re: Hurdish TCP stack
El Thu, Apr 03, 2008 at 05:16:24PM +0200, Ludovic Courtès ens deleit� amb les seg�ents paraules: >> Well, I don't know how rpctrace internally works, but I suppose it's >> someting similar to ptrace, which gives information at "use-time", while >> such a filesystem would need some kind of introspection mechanism on the >> destination servers, in order to be able to figure out what methods are >> available, as well as their signature. > > It should suffice to have information about message IDs, rather than a > full description of RPC signatures, which would be complex. `rpctrace' > looks at the IDs of messages that are exchanged and fetches RPC > descriptions from special files that map those IDs to RPC descriptions > (roughly). But as I understand it, rpctrace can only look at ongoing messages, so you won't be able to build a FS interface for functions that have not been called before, unless the translator exposing RPCs to FS already knows the available methods (the IDs) *and* their signature, which renders the translator as totally non-generic. My idea about introspection was to have a dumb and generic translator build the FS interface for any given server. >> A quick hack to that could be to store that information in a special >> section in the ELF (generated by the idl compiler), which simply lists the >> available RPCs and their signature. > > You are not necessarily able to access the executable that's translating > a given node. A better approach would be to have all translators > implement a "meta-interface" that provides RPCs such as > "get_supported_msgids ()", etc (this is similar to what D-Bus has, for > instance, except that D-Bus is able to produce a stand-alone interface > description in XML). The server-side RPC handling for this interface > could probably be automatically generated, with special support from > MiG. Well, the only idea behind embedding that info in the ELF was to avoid having "useless" code in the binary. > Anyway, I'm not sure there's so much value in doing this. ;-) There probably is none, except for the case you want to expose any server operation through the FS, which I'm not sure of its worthiness. It was just a random thought from the /net FS discussion :) Read you, Lluis -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth
Re: GSoC project about virtualization using Hurd mechanisms
El Tue, Apr 15, 2008 at 08:48:26AM +0200, [EMAIL PROTECTED] ens deleit� amb les seg�ents paraules: [...] > Well, for one -- as I said -- the hypervisor could be completely > transparent, just emulating the "real" device, so the subhurd doesn't > even know it's not talking to the kernel. This is more complicated on the > hypervisor side, but has the advantage of requiring no modifications in > the guest system using it. [...] > So unless I am missing something important now, my previous statement was > false. Having the hypervisor (or the BPF server) implemented as a > translator should not make things more complicated in any way :-) And using a device hypervisor can have very nice properties for mutually communicating virtualized environments: http://en.wikipedia.org/wiki/HiperSocket Read you, Lluis -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth
Re: L4 etc. (was: GSoC results!)
El Thu, Oct 02, 2008 at 02:53:57AM +0200, [EMAIL PROTECTED] ens deleit� amb les seg�ents paraules: [...] > In fact, the only Hurd-related microkernel work I'm aware of is Neal's > Viengoos stuff -- and even there, although Neal certainly had Hurd's > requirements in mind when creating it, I don't think he actually intends > to port the Hurd to it himself... But what is it's current state? And which are the insights on its design? I know, there is a latex document in the repository on viengoos, but I haven't had a throrough look at it and so I don't know the answers to those questions. Just knowing if the answers are there would be enough. Thanks, Lluis -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth Listening: Fates Warning (Still Life (CD1)) - 12. A Pleasant Shade Of Gray XII
