[Patch] Bochs with 4M superpages runs L4Ka
Hi, [Kevin: would you please have a closer look at this patch? I'm not an x86 expert and this is at best a premature first try at it. -Thanks] the following patch: http://home.kamp.net/home/farid.hajji/l4ka-bochs/ enables 4 MB superpages in bochs. With this hack, you can boot (among others) L4Ka+root_task without problems on your favorite workstation ;-) (at least I hope so!). Please refer to the file SUPERPAGES in the patched bochs sources for a quick overview. General instructions and screen shots can be found on the above URL. BEWARE: That hack is very alpha and not tested at all! Don't rely on it too much for now. At least, it won't destroy your system, since everything is emulated in software. Bochs may be slow (it is!) but at least it's more secure than plex86 or vmware and it runs on non- intel boxes too. If you find any bugs (e.g. bochs panics()), please try to track them down and fix the sources as far as possible. It is easier than it sounds because bochs sources are very clear and because you can insert printf()s everywhere. Try this with a real processor! Thanks, -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: first experiences with l4ka on a real pentium
> > I didn't try anything else, because I was not able to compile > > Dresden's L4Linux on FreeBSD (I used l4ka.org's glinux binary). > > At least the root_task seems to work and this is very good for now. > > Based on root_task, L4 servers can be build, probably with flux' oskit > > (which compiles w/o problems on FreeBSD too!). The we can start thinking > > about libmom and porting the Hurd to L4Ka. > > > Yes, this is excellent news. > > But why do you feel the OsKit is necessary? It seems that with a working > L4KA it should be possible to follow the example of the hello-world template > to produce servers of our own. Or perhaps it's just easier with OsKit? > I must admit I haven't taken the time to master that beast :) Of course, the first servers would use the bare L4 IPC calls, but somewhere down the road, you'll want to access a disk and here comes OsKit to your help. The OsKit libraries provide plenty Linux and FreeBSD device drivers, filesystems etc.. You don't have to maintain this widely known codebase, as long as OsKit developers do it and the OSKit libraries are not restricted for in-kernel use only. They are plain normal libs that you would link to your L4-servers, overriding functions as necessary. It seems like a quick way to put up an OS personality. Porting the Hurd is something else. Here the libraries are already present (glibc and all other hurdish libs.). Traditional gnumach includes some old device drivers, but that is expected to improve with oskit-mach. Porting would mean to add L4 sysdeps to glibc and to implement device drivers as user-level tasks that _may_ include code from OsKit. We could start this right now, but there's a drawback. Without a proper abstraction layer between the Hurd components (mainly glibc) and the microkernel, the same work would have to be repeated again for each other microkernel as well. That was the reason I'm interested in libmom or a replacement thereof. Thanks, -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Porting the Hurd to L4 (glibc dependencies, droppingglibc?)
Roland, > Look, whatever you want to hack on is fine with me. If you contribute > changes to Hurd and/or glibc that are clean and do not have negative > consequences for the ways we are using the code now, then we will probably > accept your changes. But the development priorities of the Hurd project > per se are very unlikely to go in such a direction, and I am not interested if you would let us participate to your concepts of current and future development, such discussions would be more effective. We can't guess what you're planning to do on short or middle term if you don't post your ideas somewhere :(. BTW, porting glibc to *BSD is not on my priorities list either, as this is not what I'm currently looking for nor interested in. There is enough trouble hacking up L4 servers already, without having to port glibc. I'm not having the glibc expertise to do so anyway. > in a whole lot of chatter about the merits of various wildly different > directions I don't plan to go any time soon. Less talking and more hacking. Look, I didn't want to attack you or whoever wrote up glibc, so there's no need to reply like this. Basically, you suggest nothing less than to shut up and do our own non-approved stuff without asking for feedback from the list. This is asking for a split in development :-((( Sad perspectives..., but splits are necessary sometimes. Okay, this discussion is obviously getting us nowhere. If anyone is intersted to help me with what I suggested, please contact me on PM. We could try to do "less talking and more hacking" in this direction. -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Porting the Hurd to L4 (glibc dependencies, dropping glibc?)
> > Is it _absolutely_ necessary to use glibc with the Hurd? > Why on earth would one want not to? The Hurd developers have no interest > whatsoever in using anything but the GNU C library for the GNU system. The Hurd is IMHO more than just a simple kernel replacement of a glibc- based system. Due to its flexibility, other applications like host-os subhurds are possible too. Just because it's 'oolitically correct' to stick to glibc doesn't mean that we _must_! Other GNU programs are not dependent on glibc either (thank goodness!). Another reason I'm having problems with glibc is very simple: I can't figure out how to compile that beast on *BSD systems yet (or BTW any non-Linux system) even at all or without _much_ contortions :-( But this is just one reason. The main interest here is to 1. isolate the ukernel interface of the Hurd from the more generic C library so that it can be ported _separately_ and more easily to other ukernels or host-os(s). 2. obtain the hosted sub-hurd at a very low cost (in terms of efforts). -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Porting the Hurd to L4 (glibc dependencies, droppingglibc?)
> Anything that can be done to make the HURD available on more > processor architectures would be a good thing. But my impression is > that the work the needs to be done is to port the HURD to OSKit Mach > and to port OSKit Mach to other architectures. Then you would still be stuck with Mach which we try to overcome. L4 is completely different from Mach and I'm wondering how you plan to port a Mach variant to L4 (or even implement this sub-hurd hosting on foreign OS)! > Since the HURD is a GNU OS I would suggest that glibc is going to be > an integral part of the system for anyone wanting to run it. I have nothing against keeping glibc as main official C library for the Hurd. I have just suggested to keep the dependencies of the Hurd form glibc to a bare minimum, just like other GNU programs that are _not_ dependent on glibc as well (!!). Having the option to choose betwenn glibc and other (POSIX-compliant?) C libraries cannot be that bad, can it? > Nic Ferrier Regards, -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Porting the Hurd to L4 (glibc dependencies, droppingglibc?)
fit below
(or inside) libvk-mach but has higher ramifications too and cannot
simply be put aside.
I'll try to slowly chew myself into libports but if you could
enlighten me on the purpose of it, it would be much faster.
-> If we don't use mach anymore (except via libvk-mach), what parts
of libports would be _really_ needed (architecturally)? This seems
like one of the most important porting decisions right now.
-> At first sight (I didn't analyze the code in greater detail yet, so
I may be plain wrong here) libports _seems_ to hinder a lean
L4-style ipc thus adding a lot of ipc overhead which happens so
slow the Hurd down anyway. I'm I right to guess that libports
is mainly a hack to get an interface to the complex intricacies
of mach? How much of libports _is_ actually hurd, and how much
is mainly struggling with mach? I'd _really_ like to drop libports
on non-mach libvk hurd's if at all possible, or at least replace
it with a minimum non-mach subset.
3. Once the libports issue is resolved, it's time to look at the ipc
protocol between the Hurd servers (and their libraries). The protocol
is mainly defined in hurd/*.defs, which is IMHO [one of] the most
interesting part of the Hurd.
Of course, .defs are transformed by mig into mach stubs and a port
of mig would then generate libvk stubs instead. Porting mig was
already discussed here and it was even suggested to have a look
at IDL compilers or somesuch. Wether this is overkill or not, it
is finally irrelevant. Let's assume that we port mig to generate
libvk stubs in a fairly straightforward manner [it must still be
checked wether this is possible. It all depends on what the libvk
API would look like].
Now I'm wondering how to map such mach stubs (which ultimately all
end up sending or receiving a message from a mach_port_t) cleanly to
a still-to-be-defined libvk ipc-API. If we decide to abandon the
asynch IPC model of mach in favor of the more efficient sync ipc model
of L4, I'm wondering what we should do about the routine/simpleroutine
pairs often found here.
One example: the auth server defines a routine auth_user_authenticate()
which inherently returns a value (newport as a mach port) and in addition
to this a simpleroutine auth_user_authenticate_reply() which sends a
non-overlapping set of data too. I didn't yet figure out why both
interfaces are needed and how they are exactly used (probably deep
inside glibc/hurd???).
Completing the handshake between auth (or btw any other server) and
its client(s) need not be asynchronous in nature. Basically, a thread
in the client could block on ipc while waiting for a reply from the
server and the server could provide a few service threads to receive
sync messages and service them entierely [receiving on a port-set
in libvk-mach, select() or pthreads in libvk-{guestos} and ??? with
L4 lthreads in libvk-l4]. Basically, we need to rethink the way
how hurd servers are being ipc-ed to in general.
-> Has anyone spent some time thinking about this? Please share your
thoughts with us.
4. Other Hurd libraries, bootstrap process and a lot more issues I didn't
considered yet. I'd prefer to gradually proceed and concentrate on a
few well defined goals.
-> If there is anything fundamental there which contradics with 1., 2.,
or 3., please let me know ahead of time.
As already said, because I can't compile glibc on my FreeBSD box, I'll
try to modularize the work by compiling one bit at a time. Starting with
libvk-freebsd, other parts like the ominous libports and certain servers
could be compiled against the guest-os libc if they are somehow using
POSIX-ish C API. Even without any libvk-* concept yet, I was able to
compile libihash [spin_lock() replaced by pthread_mutex_lock() of
FreeBSD's libc] and libidvec [libshouldbeinlibc/idvec* files, having
to tweak a little without shadow.h and the non-reentrant getpwuid()s],
so there's hope after all ;-)
Any comments, suggestions and help appreciated.
Thanks,
-Farid.
--
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
Murphy's Law fails only when you try to demonstrate it, and thus succeeds.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Porting the Hurd to L4 (glibc dependencies, dropping glibc?)
Is it _absolutely_ necessary to use glibc with the Hurd? It seems that many hurd servers and libs are using glibc like any other C library except for: /mach /hurd /sysdeps/mach and of course MiG-generated stubs in /*/.deps plus a few places that use mach_*() syscalls directly. There are some few more dependencies which would have to be taken care of. To help porting the Hurd to other systems (not only to L4), it would be a good idea to: 1. retrofit all hurd specific glibc functions into a separate library (let's boldly call it libhurd). The reason for this is to reduce the dependency of the Hurd from glibc, which is not available on all systems. 2. clean up the Hurd libs and servers, so that they use (the rest of) glibc rather conventionally. The goal is to be able to link the Hurd against libc's of other OS (plus a ported [part of] libhurd), thus "borrowing" features of existing host OS kernels like threads, tasks, etc... or using ukernels like gnumach and L4 directly. Why? 1. The Hurd could be built on non-glibc based systems and run on top of these (as sub-hurd). I can imagine running the Hurd on a FreeBSD box, where the Hurd uses dedicated partitions (or vn(4) files) and where it is linked against FreeBSD's libc (and an adapted libhurd[-bsd], see below). 2. Misc. abstractions that the Hurd needs (threads, tasks, etc...) could be either implemented by a dedicated microkernel (gnumach, L4, ...) or could be "borrowed" from an existing libc of the hosting OS. In the above example, threads and processes etc. would be provided by FreeBSD kernel+libc. 3. The Hurd could be run in "demo-mode" inside existing OS, just by borrowing most of the local libc/kernel services. This way, more users would be able to run the Hurd and get first experiences with it. 4. Porting the Hurd to non-x86 architectures could be a two step process: First run the Hurd as sub-hurd on an existing host OS of that architecure, then port L4 (or some other small ukernel) to that platform and relink libhurd[-L4]. To achieve this goal, a lot of work is needed (or course!). If we decide to give it a try, I'd suggest the following path: 1. First of all, move all hurd glibc functions into a separate library (libhurd). Later, this library will have to be split into two parts: A hurd generic part that is independent of Mach or any other ukernel, and dependent parts (one for gnumach, one for L4, one for each supported host OS which calls that OS's libc directly to "borrow" abstractions like threads etc...). 2. Examine the Hurd sources carefully, looking for glibc idiosyncracies, that are not available on other libc's. Revert to the least possible interface common to most/all libc's of the host OSes (at least Unix- like OSses for now). 3. Remove the Mach dependencies in the Hurd sources themselves, by replacing them with calls to libhurd[-mach]. As was already suggested by others, mig could be modified to produce more generic stubs to libhurd rather than libmach. If I could only find a way to cross-compile the Hurd, glibc, mig and gnumach on FreeBSD, I'll try to get the Hurd run on FreeBSD as sub-hurd first and will start working on an L4 part next. The more help I'll get, the better :-) Any suggestions? Thanks, -Farid. P.S.: I don't have anything against glibc. Dropping glibc dependency from the Hurd is purely an architectural issue that would help support the notion of "host OS running sub-hurd" as well as to help isolate the current Mach dependencies of the Hurd. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Problems cross-compling glibc
Hi, cross-compiling glibc (new cvs snapshot) breaks with the following error message (while making $(GLIBC_BUILDDIR)/elf/dl-sysdep.os): gmake -C elf subdir_lib gmake[2]: Entering directory `/users/farid/Devel/GNU-HURD/gnu-hurd/glibc/elf' i586-pc-gnu-gcc ../sysdeps/mach/hurd/dl-sysdep.c -c -O2 -Wall -Winline -Wstrict-prototypes -Wwrite-strings -march=i586 -Wno-parentheses -fomit-frame-pointer -fPIC-I../include -I. -I/users/farid/build/build.glibc/elf -I.. -I../hurd -I/users/farid/build/build.glibc/hurd/ -I../mach -I/users/farid/build/build.glibc/mach/ -I/users/farid/build/build.glibc -I../sysdeps/i386/elf -I../crypt/sysdeps/mach/hurd -I../crypt/sysdeps/mach -I../sysdeps/mach/hurd/i386 -I../sysdeps/mach/hurd -I../sysdeps/gnu -I../sysdeps/unix/bsd/bsd4.4 -I../sysdeps/unix/mman -I../sysdeps/mach/i386 -I../sysdeps/mach -I../sysdeps/i386/i586 -I../sysdeps/i386/i486 -I../sysdeps/i386/fpu -I../sysdeps/i386 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/unix/bsd -I../sysdeps/unix/common -I../sysdeps/unix/inet -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -D_LIBC_REENTRANT -incl! ude ../include/libc-symbols.h -DPIC -DSHARED -o /users/farid/build/build.glibc/elf/dl-sysdep.os ../sysdeps/mach/hurd/dl-sysdep.c:255: conflicting types for `_dl_sysdep_start_cleanup' ../sysdeps/generic/ldsodefs.h:486: previous declaration of `_dl_sysdep_start_cleanup' This didn't happen a few days ago. farid@bsdevil:~/build> grep dl-sysdep.c glibc/sysdeps/mach/hurd/CVS/Entries /dl-sysdep.c/1.54/Fri Dec 1 05:43:04 2000// farid@bsdevil:~/build> grep ldsodefs.h glibc/sysdeps/generic/CVS/Entries /ldsodefs.h/1.20/Wed Dec 6 23:18:46 2000// -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
netfs questions
Hi,
I have two questions about using netfs:
1. what is supposed to go in the 'struct netnode' of
the 'struct node' defined in ?
If I understand this right, struct netnode must be
defined by the user and is supposed to hold protocol
specific stuff of each node. Would a simple
struct netnode { };
suffice? (it compiles okay, but is it right?)
2. what is supposed to be put in a root node, suitable
for netfs_root_node?
Asked more specifically, how can an empty directory
containing only '.' and '..' be inserted in a netfs_root_node?
This is what I'm having right now:
/* in main(): */
netfs_root_node = make_rootnode();
/* whereever: */
struct node *make_rootnode(void) {
struct node *np;
struct netnode *nn;
nn = malloc(sizeof (struct netnode));
bzero(nn, sizeof (struct netnode)); /* XXX */
np = netfs_make_node(nn);
/* create an empty directory in np */
/* np->nn_stat = { ?????? } */
}
Thanks,
-Farid.
--
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
Murphy's Law fails only when you try to demonstrate it, and thus succeeds.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Strange behaviour after cross-compiling
> > 3. commands can be used as usual (e.g. ls works etc...), > >but as soon as non-dumb screen capabilities are needed > >(including pipes!), I get the following error message: > > > > bash [36: 1] tcsetattr: (ipc/mig) server type check failure > > That means the message that was send by the user is rejected by the mig > generated code on the server side. This seems to point to a broken cross-mig > or something like that. Make sure everything is allright with your cross mig > (build it from current CVS), and the *.defs files in the include/hurd > directory of the build tree are allright. Then recompile glibc and the Hurd > or so. That didn't help either. Even with a new set of cross-compile tools (including mig from cvs) and recompiling gnumach, glibc and hurd from cvs yields the same error again. Besides, everything _else_ works as expected, so it is very unlikely that mig is wrong. The only thing I didn't try yet was to re[cross-]compile bash against libc 2.2. Maybe the transition from 2.1.x to 2.2 was not so smooth? > > Every time this error occurs, the program is stopped by bash > > and resuming it with 'fg' results in the same error again. > > I have seen this recently, but only with a very hacked glibc I tried > locally. So I know what you see, but don't know what happens in your case. This is very strange. glibc was cross-compiled directly from cvs with no changes at all (yet). What can I do to help track down this problem? > This has nothing to do with the TERM variable. The TIOCSETA ioctl is > failing, because the generated message (sysdepds/mach/hurd/ioctl.c) is > rejected by the Hurd term server. Hmmm... Thanks, -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
A memory-based filesystem for the lazy [or impatient]
0U_CI*PFW0FL.QS<*1$B+%W@#/CL*E`9C@.$;P&MU%$>P:0Q[IP
MHTM,>L;M:?(:I,9V_&=7XF40IN/*G!#'P(9.LC\<<1-=&>IT$B)HD\Z"`TNO
M&PKO`COG:A4I-#'/=#)2)L0NQ\;78J$PY<9CEN1&:4W"9H)Y<;)#!)*R=B`/QO]>GD&1U;)-IJR#C>&GCF8I')\-*72`6+0
MY+-Y4)E;7(<8N!%'409VLW?BDQ'"Q^:L3&W$M;($J<(U'(OE>&*:#&^]SA@Y
M\Y*$`UK?P7,#-NIA%++S=RYJN8)7F-$HZA&GH,9(/4!(/..`I)<.?$KVJ/O9
M,TNG8,\_4_%D#]AU@1W/,^CP[HY5_+^]G[DIIT&.](3!Q[#
M'1JS1"<#-J+P?.V^/Q8@LMU]A"AN^V4./V)FF_99PHT/LX@O/C_&!41I&+/I=6
MM>!0OLF-8E/:,KJ+1O#`L@Y'\4G<)^%'\1!ZEAT-9IZHOY,2M>
MV"4["JO&+&&:8711*CP?+5::SP1]`1
M#V-6+P.O9+O`^XIKQ&XV-;EE_&T!G.$2PA>LXD#-`R^$:GB01_UL$4BX>:1G
M!!+4YMP"`\?_<\Q'="4`0[_%H\`>3<`RX@PHT?CR2T3F1<.TA52:3)>$5.9W
MG<`R*#7+,,-&(P43CS)=GL6TJ=BCE%_VHU.ZYC:D&<8K(7D5_X0EL8$]1G\\
MGO56/Z4=XEC8$"?&Z',YM4N)V1>N"\%)`-XZV?!N*\`%O.&1I<*<-H&]ZE)W
M%".-J,I2!XCGJ!(01VPR=T$?#9][T>R((\(H["6%J:EB$/S$910HMDA]"$)H
MC1P9Y'X+'.*GY47F)AI_7Z$Q9$D@,K011-K/F9:.DNZD(]-@(J*Z>PX4BWH(
M1+(F1-M7H/1H&=]@O,((7F:+<5[@S[0+TTU
MO@@YGH][D@E#:ZK8I..=Z9FT+F_#!3%2"+%V+R!!8
M`?"[#S*I1;E>NGGVN`L'?&)!G^[F)#S%EI5>$V8D1-"C+:ZX#S1;@X:R=UT>
MEGY,+*V^'@3V9,R2/_H2.,\V4+G>#$9QZH,K.K(EHAU+=%&V$/\H#$*B^PK&
M:MZ]R"W2YE,(,@Y9H$/!X;%&/([$Q3KF*T\4E'JWH!("6_:"T60PM?4V^%8Y
M'40A"L<6V0!V%VRDGP0>LYX@2C_N\8#.2,UH-!XS1313@!;8D4N$!B-82(&+
MZ-`)8V%R)U$T$,1%ZYPQXW(M>"<,CDN&,AY-P&ZC+W8LL73'+;*;1$()&C5A
M8L*KVPBLEE?3;I93GX_!\?K,=23-*^
MC$XXAW$YP2[\926=$1;!/().TF\59#=-,8\NHM,/XW-)N&`I_V.)*Y3'2*LG-4M$V9A\_Z#'Z_)89L-'8D75^E@JIB[I3
M*%`/5A*?XSMFNY->19WM,DX)9A(9)<0N6'@&B>+;&(^ZKA<`T#Q.P))^=9$J
M6];=;;TE]`."*^8K);.L^M>)>FHD8?C]*UT\(5I"L)Y,*%L)&.67UMACL3!N
M!$"//_$226PT!V-=,'KBMI)&JGCA#8(XR9]HHY9N9`,L,(\$+
M5.)Z]($DJI-A+),IR3A$'3*P7LV\K%%T&HZZ?01[@:$Y0]Q0PODC"0<>TH>5
M0K(OUK^/'<+4?6)B!,;(T_\QHYJ.`U]UA+@DENXTY-%EU3MA0O_8T"F=L>"0
M#<7B31!]BD8B_EK%F>B&Q`]DUF9[`E0R(G:N#VV&%:?2F:P`K7E[`-$B%FO.
M.3!=>'J*7;+=JLPCZ\"NS.HH*/):C"#YX36<2)GC-,U%TI]PEBF2>I&`$%GT
M!*=GZQ/>-\-")R.+_[S9"=IDF(:4,I/*K5[/JA>74)P]1$@AII;]:99!HS3.
MU.K`D9QH,F9\`XYL!OT-#NR-:_`0AV
MA7.$ZFG@63]B6C<2G3(30C@Y$`=5]5/R^&K\BMYY>VO]G*3S.4&A-?GE\`'K
MX76HM^0\',4$_Q.K&,J4A"`ZPHT]IBVL.(YL>F6ANT_,\\]%'<\E^0T?SBY8`L$4W@R
M*_.G2ICY@(3V%^Q06.IS([A/K`LXE9R#K
M94A%-&(R%S8+RG&<.\J)1C#&J:8V+YDA$AT6T9L"CRY#6
M'C,U+WI.@TP@*\69U$*277^2LF02IFG2B:U"C*Y`V.'DA!R]E$BV*-M>\##2
M7J4":D35+/W"Y&+5DTGT$PD%_7[H,P[9BFB5K^G@+[#IX.V"%"$Q=.*1968K
M4^OQKPN;^$`U5!\':QX;!YVJQS&U_F:8].6`()<$[E[":D-9T9S?/2+RO2ENP>L=+)9W`SA/INC)&-"1`R%+/\AX2U(*
MJ2F:H6$HZ9*9J[5?&;#KA)HQRT('4]!GV6UF1KDS>C%A/C\-9K&5.2RIZ:V3
MR>F9A]OC*/64G.?#B(,S9DRAH"[R-@-6`V/6,IX!4"2*(%'7D/S'2G3A7WVN
M)<=+!`*I@-[HTQ"*7!:@E-1;=.ZQ*K!F0L%$4#$.FL]RHH3J]'^AFQJW,%+C`R
M(4Z%YS/8!>5]216,JU,V=\9@96)BIH7&T;D:?8]B3
M&;OI!X5-+(@XZNJP41,["L>S"H-R':M_PXIS3@V%"Z3`#Q'9WD:+T@)K2-8W
MXBDBESBO2_0,_'9>=+L9%XUASH[F&$.M"X6BIY@H@VHN>Y,1VZMR#BLRQ,FQ9-.Q>8<$"<*BA/91CT]3VL_@+Z&
M4GQG6D[@*7
ML3/IAX1IXU%G^=U[GJB!*"6M/<4V\LP2!<]5=:`<"`@%
M_K"PH&[G5&[#R8@QV`R=&YW,1.DS_R6WWO,^23.W"BCZ"52O5'O&ZCKKJ*>Z
M.E$LDL>&&?.&SS%*D.?:N>0$I_#KH&LM6$>'<:+X)4SX
M([9!PKMO:DI1-[#0SJA+91+V1E1\+AG24OJ"22#\6CJ>S!82L\0?/58EZF3H
MS+WL1+72309R`%VB/EWV+&57*Y.>,
MUCM"B'A8L\:UHIYB1;U>"QB+$Q)9]PF8#ZQS*`M&(R`ME4X!*QGTGUQEEBU?
M3A<J6Y>4R+`8S1$9G,>@<``1WW:83FPS.VH.>6Z#F]$%T3
M6UP@B-@MI>+2<><^S84#B#IGP$S`.8D"0;81@CHFJ0[`Z0>W!V*<0AZ`2AX7
M$Y.?T`V&B21EA.Y-,>0T<"Y'H3!+)TGW:J8Z^5&-/6'FNJ)CIZSW!1<"E70O
M.'(X-6LEJ#2PY8[FE%!B'@!<+*X3"F6@7@RMS>]#HA013$>+`7)'48)A/&*W
M=:MF2G%Q]0L)C^#@YU2FF7@+QSQ;66
M*ID4QR3;^FADRG-/@9IGJ*V3F+40VDDE(^LUD!MJ=K6P8`8X3*T],VBDFN5E
MQA84C&17SH8:H$TMA'G:G,)?0C4AQ[L>R9)*VOHJ("S1_IH[H:=OZX46*Z<
M&T(XDO,(ERP-F!XX)6/J/)XU3`-$C/?=YO\@D.]F^SY0`_,A&^.3B9J2GY#QQ,CLB?\2WH4L(1LF(^^14\$G_*@MU
MVMUS]>'X_!LU\ZS]?.OHH&T.7[>1.^;5_M8;LWU@O6)?F)?[[;;9>VF>O][:
M?]6NH-U^&RW\ON`CZW5`K?;X[_:/",4VJ`^P?7A(O3W[R6R]?4N=;SW;:9N=
MK7>TF^T?G[??'G)VOF`/W;_;IOD<'&[A@^U=@V0VV[NON$,XXNYOOWI]:%[O
M[;QH[[.W[@J-SA]*I;KV`2H8_[#](K^HI:T#FO:2*Y9G)X_%H7#>7[=W7U1,
M>YL[:O_X=K]]0.L/J._M-S3C-KWX>T3[0RFN?A'F^-
M;6M[I\E0_T&QQ!X\AV]18X^WD#JA#=_?/OBKV3H(=&/_ZVC+=42[2WV\V=I]
MS@=5.$@LU_RT=P2J0>O>>8$&@6V`C6J;%^V7[>>'VS_0\5)+&N;@Z$U;]_O@
MD#=H9\?LMI%W:6O_)W/0WO]A^SGV(=AOO]W:WC?L([V_W^:<,();FC4<'D%)
M^P?`P-'N#E:[W_ZO(UK/#$A`'UNO"-JPF=ZY!^^V:7"<4/'P*_P)O<@._R<"
MHSWS9NLG<?6LSWLP3.:SS9/BR:"#<$1O=AZL_6J
M?5`)'!#PT.I,7C$';]O/M_$+O2?0H[/>D5VA6_1?1SA%>J"=F"TZ3BP-<*A'
MACL(6-NU,$)C%^]E*1N[`'^`BYV]`P";)`GE&=._S]IHO=_>I?WBZ[3U_/G1
M/ETMM,`7-)N#([ILV[M\*`'6R[=Y>_^%O4^\S^;EUO;.T?X4C-'(>[2%Z))A
MS1V(!;*#O];3,[E;^Y-Y34?QK$W-ME[\L`W,(^,$=!<.MG5/
M]K0'W4=&;!QK2NOC]C,<^.'[O\5ID^)/+2AQ00>V6"85/>LA@W5UB
M>936I8!CI8]=9())AC:IG^]-Z46YJ:^>DLQ3C@))QX'+'#I)'142`4_E;@@.
M6DH.MN+HPI892YUD$H^#/$402NC"=J:JHGH!H.
M<01UITU25\@GV$_^WOH->!NPG$I=-.GZA"20GB'"'XI+D=0+9-]P+H4[%59]
M=47]V\)JPOAH#<:OJGRK^F/QHORRTKE"]&A!3?2'M"8T:UG!WL[Q&WL_.1SRH\9`O3P#5?:^SM'JUXNU[)+4+S]&9UAQ!_U
M,8[4(,DA`^Y!8Z>;4-'9)-/-\
MVT^BX#RA+JL=FL%'5F2<1X,);5ATGE:KP-HL/*>36"RY+L9?HT9TL>R,A_!C
M;H)2T[._5B_/H]&92.QVZ,@A%]O&0#S885Q&X%RFC,M";I:R
MR!3+:\2]P*L49EZK9WH(OXEAGT@$>TU)33<"4XFO^"FY2KI7@\C>:-"_DRLW
MD/@#91/@&P)N1!&N#DX=_=V#\V48Q-A'D-,`<@@O5\NTCB]IV:]W_1?,QKQ&
M_>,1([PGXCJ"8&^"DL,KNFG)X&G%-(@O&\5]SCX"!D5>5)"A(XUM3-12U%F4X#\..?+VLS`B_RU249<&:UD8^*0AAE1PELTD`VG$K"*64"
MZP_.$9E`\D*9V-PH,R&F@KVY_!$]37KJ_%`"[=PJC00I7%JW4!O&W27FS4;,
MS,AN$-A:7VVM-@TOWK0_#5%N%9+S
M&RU[S%XO6;7R7(EJ2XA>3S2P;$JLP5#F)??].OS'/V+SA`>JG>&/_TQ.:A^)
M0M4&T5A$'1&[G>(8/,UMA!T)<&%QARM6.8^9\R^2=SA'[;7J\FO%'?9Q(]D&
MW=Q&O)FQZ&L%'*F)DQ=Q;$#6UTDX7R7@8$_1R6?)-]]$O,D[:J9^/J#;R3?3
MXLWZ(W,8<;WHM^+">C!!!ZNK]8IYEJ1CM"1)!Z).HU%MK-8?&$Y9%LRY-L1R
M5>?]!,'1@,63473*[A?>9Y8#UF!WV@XI1UZ=&H"=`1$G@WH-UH$$1=UE0B6P
MR!\-[0K!UL=RS8D3<)-4OWD-7H!-/Q#GJ%2,@NZ8B&2=Q@B<:)\!I
MF#($X=P5A'%!HB;.N3Y(-!L*_$RL&=?E-U5!P]T"A7KQN$E&SBVVV+W`E;:A2O"!T"6)'=PR[22/:?&;9($!,GQO3=//)8'2<](ZY#,!3,>5O-I!8]6,OK46?QDU3_`IYC?WB
MW.[]&,$W8R-UT_%I+YW^.-CJ:`T073-66^R".71.HDK,P&ED"X=@723Z07ZH
M/LV-\UZ[_Y"]F-!3VR\_YML6)^]Y2\ZZ];3QP24]?%*=D_MPSHLG50>?,MD"
M\!@'/.$T"F#[=?P)PG#\WGZ#@>Z,G//G'MX,M.W'X<;)V&R`@>NH.70/Y9YSZX2!!9
M2V@.`5X9[U()@-AZT:75&#BQ-KJ(V5F*=I=W8@Y\Z&0$/@K;$9A;@$%VWC;-
M<.HT47#$T=)MR<"X_,5:V(S0]44<>HV8H,(%!"Y-@(P^DD(Q9/UGRY=1>.R\3S^:CG_UR">57,NES/1*RND(%K+
MJLP)J1B/KL1YA&G&15SVJ\^I0K2]W=[>DT36M*E'?,LL_0R*_,O=NW>)T1[2
M2ORPK>`[`\&K^O.GBY[]ME:OT;/:Z<_TLM,U(IO2[U`7!9V.J;Z#UJEZ:JH=
M]PD]3=P?2;Z5>Y$U,-6^'"NAECXGU<83V?!JOY>BZ$IQ*+`SU=QXN2=3@_IO
MBTUY-PB[3889T!<0.EB.3Y\^Z;KE?ML>@AQBI%:FEF%9+H9BUNI&ZXF81EW&
M\Z!^%$GL@:31H#&&-/HG\T\8'75*@4A[_--XU#2F2H#-Z;U;]7JMOGZK(>4O
MU;9+B784G&KA9(E>X?<@Z^<]),%JHUF%T/FH55]KK3_XT,J2ZO_Q37E1AWIM
M^%RS-%^*?ICVX4@XDU\TBK#8/L"*C[,ZNM3_).+9[;*WW?BAS7P1=8R="'_K
M1G<$J)\BHR0![NDI)Y+(VV`Y`5]ZR\W>("'_0RNK_79STZSDFLQL)QHOI\I9
M-NI:=I1.')L1CFVQS'7,I[:2NQUHL1YL&\X6<^DW=@C6=CBK53TX)62WIBU:
MYGT-/_5&/!PT>U>3\?[)9RRJYOL(D/6\WU6VZB-BT6X)2:E>OES_M2
MB#=_BBK=KJ)QHU[^TBE\[I?,1[@92#77S;7;]'(='`TD323Q`H.N\XMG[M1S
M`3#(_=;3\XK''VOM6($K$X)-O25T
M/6JMWO:*:M/91[OZH/QYGWX9>%T[A\_]\@O`2WLI@A<*WK,517(]3($6NZ?8
M4KJC"$%T47<.3*W59T$+/;4P5?]M8&HV!JW_*\VFVOQC)L-'#"L>2@])ANX9
M]%J"_*"2:64<5C*P:A4\=_UC(J9Q:CD9`%A;6=JCJ[1
M>$YK0#/:D--O>7P75G`S:[SQH%%_^'!CS7&K30';J`[<0ICC@-!`UNPLX1P(BZ$&E&Z6G_SK'4C([[Z
M<+W`B#^JWVJ!G\>"KC;6UA\T'\YC07>3RXH[`T3FL`HFKTJDQEC.2GH2#U;.
M/T9H@0[TUT:M@0HAJ]6_3/I5-@!!WFG_>-@T+P],O;9^4C&/UE?J#U?JCX*7
M6<_]\"3J;P9[!^R.TH+2?X4M2\^XN!?7@6S4FVNFU$].061>CD*)_YU^]6"#
M5A@/DBYBB%;K#YJ$;]!+&C365S?T=U-:K]7K]\I&G/!5GHU]6*:=(9/@@"2^ZX,\-I.ZA1%TKC:W[<9ZD;4D)=
MO%-&WA`45^3.G=^6])W)*@7-/VX8D/T)-"Z3@5;NFJ23L#]U>^G3;CS**_I$
M)&9@[FJ#H#NZ_#2JXC\&WCFHBL\^`^BU#?LY02F`5"Z(/ALGX[!O&LU"WTTS
M2H@R<48@^PNZ;C8?/LSW3?AZ_#V[A#`L0ZR(DN:2ULY!MID"-@M1S/:M
MQIWL$ZI3?U+?Q"H&+"9V'".F="VWG43&W'*GB=O>`'@)JC;J*,HJZF7*Q&/-
M?Y$>$]I5/(-,@>?1&&XY1?@Y@I'4X9^+L#]!7>-U=HE%3E?,OQ-9?4!`D$W"
M5PIHZ$W8LP?N4/.H`]=?MW8:N`URM`^B6@HJLYIKV&S)WNIG8K*:I%*%=!@B
M7;Z]UP7E:M;'ZG5]\#TT)25&Z"I,/Y9=I\6^UEIT'&/Z113TG"_:NR625YQU
MMT[SVRW.S%O>^BVZLLM>25;[U1_#UJL?)W7865ZI5-=/+RI
MB^+JIGIX=(L>;ER1Z^V7L')2Z52(Z_RUE;.PJJ$Z^B0F/G?T[],/GD)>B]Q.
M_X@A(T1MHA#`ZV^VAQ<
MI3]4P5UQZ2FK.,-);>$NXPA\9I'H/%'A\W@0?ZJ8BUXXEE*\%F_*59$!&Y5F
M9?57.B9B6@/?HX3^/J+O,;38P6GEN]&8?2ZWNM0W2I^?T6ZVS/=KCZK-QFJC
MNO&@NKZ^'CP;)7&'D'$W&?72\:AF'A)M?5%=:ZP3@_77,!RA&->K:,0Z>^IF
MCN]*4#6?\W_?SWL3O)F,AF=7Q`3OA$18V1%8J?#-'
M+A2]18U[=I[,7Y_93I3KK;6Z[T2I'02&^MA)3F=T\AW>[4<:'X(N9_8IG:*M
M5KR6A!&H\�/0US5Q-8FB=$5U>8J-;.GA8>(ZH\_[37(>Z_T'#<)7J??S89
M$/QVI]K%2?$1`L[SSSJ8"QXA`8Z9702=:X%_D"KH>-[]@J#2M&
MW#F.Y<_'VE0,UOB+NR)F[/V:5!7'VY@K%:,N,X8S3\QJOI*Y*PQ/BY$RS<1U
MG!*7<"^UEG,=_F](&Z$URPL%SIOKZUZ)\]PLS29JKX_I0O`,+MXW/U0,*EY7
M2%R5,LI8*S630NS67OHL;"K=C';[K\<'[4,WLG[UIVQL8^RF+4XK2;_K1I_P8=0ATE.EHZGTQ)O%1AG4_2PYLR?Z+>"YN*(72)_"%UTZ^E(#FCVOM5OM5??>J=,DUTK+A*M!U78N%4/#OWMT)+A
MWFX4-@ZSMZVO@3+Q)2J.NN8?EULQ-/QV3UOFO;^IAJE'*=ZL$TY_HC?8?/]]
M7-BT>QWZ*D[Y;\SU??RA;/[#R&\DBBS7EO-G^>%O@R5;G%R7SHIU6?OGK)0_
CFU[JNK_410'TQ<_B9_&S^%G\+'X6/__"/_\_YSOR@@"0`0"7
`
end
--
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
Murphy's Law fails only when you try to demonstrate it, and thus succeeds.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Shared-Memory for the Hurd?
> > * each shm-segment is represented by a pseudo-file managed by a > > fullsized translator settrans on e.g. /shm. The translator manages > > vm_allocate()ed pages just like in 3.) and 4.), mapping them to > > the pseudo-files [that is: shm-segment 34343 is mapped to /shm/34343]. > > Yes, this is a way to go. This could be a derivative of tmpfs, providing > only a flat directory (Roland suggested /var/run/sysvshm) and only accepts > certain file names coresponding to a key_t != 0 "with a funny behaviour > about unlinking open files so the SHM_RMID behaviour is right." (Roland). > > Farid, this is an excellent medium sized project to dive into the Hurd > inners. Are you still interested in implementing this? Yes, sure. Though I'm currently extremely busy with an urgent project and I will not have the time to start this Right Now (tm) ;-). > > Notes: > > * shm-segments are visible as plain [pseudo-] files and could also > > be mmap()-ed, or read()/write()... from other processes that have > > enough permissions. > > Yes, mmap() would be ideal. Agreed. > > 5. same as in 4, but much more harder to implement, since there > >is no good template/hello for a full filesystem translator in > >the Hurd right now (besides full-blown ext2, ufs). > >-> What about /procfs translator? Someone wrote such a beast, > > but it is not in CVS. Where to get it please? > > Well, tmpfs should be a good start. It isn't functional currently and not > tested, but there are only small changes necessary to make it work (coming > soon). tmpfs uses virtual memory to store the files. Yes, the source of diskfs-based tmpfs looks intersting (I didn't test it yet). As such, tmpfs could be extended/modified, by adding an RPC (or a family of RPCs?), which would loosely match the shm*() functions: requesting taskRPC messageshm-server shmget(CREATE, ...) > open(O_CREAT) > create shm-segment shmget(OPEN, ...) > open(O_RDWR, ...)-> verify credentials shmat(somewhere)> attach(task_control()-> vm_map() shmdt() > detach(task_control()-> vm_unmap() shmctl(DELETE) > unlink() -> destroy shm-segment Note that most RPCs are just simple file operations (like create, open, unlink, ...) which are already handled by diskfs. The new RPCs that need to be caught by a multiplexer are attach() and detach(), which will pass the task control port of the requester to the shm-server. The shm-server would then vm_map() and vm_unmap() the [parts of] the virtual memory corresponding to the shm-segments into the address space of the requester tasks. Would this make sense? Thanks, -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: MIG->Corba
convinced that it will be necessary to respecify and then reimplement the Hurd from scratch, if we want to ever get a chance to obtain a reasonable amount of portability; be it to other cpu architectures, to other ukernels, to guest-os(es) or to embedded systems (I'm not even mentioning distributed systems!!). There are just too many Mach idioms in the current overall design, that it becomes necessary to break everyting and rewrite :-(( Finally, the biggest problem of the Hurd is that there are too few developers! We keep talking and talking, but when it comes to writing code, the work is done by 2-5 people at most. So how can we remedy this situation? If you understand Hurd sources, write HOWTOs, write docs, manpages and example translators, implement /proc (and write a book on how you did it!), don't just cite OSF mach documents, but write Mach tutorials. Draw diagrams (gpic is great for this) showing how the hurd servers interact with each other and with glibc, explain as much as you can. If you help spreading the Hurd coding know-how, you'd bet that we'll get new people with fresh ideas very soon. Please feel free to step forward and coordinate the Hurd Documentation Project. There are a lot of links that can be centrally managed (some are already, but concentrating everything at gnu.org would be best). Besides links, some editorial work is also called for: Write (or get someone to do it) summaries, abstracts and background informations that help put the pieces together. Write man pages for both gnumach _and_ libdiskfs, libnetfs, libprocfs, ... Docs are partly available in header files, but that is a bit terse for aspiring beginners There is a lot of things to do and you can really help. Regards, -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Softupdates and the Metadata Problem?
Hi Marcus,
it was nice to meet you personally at the GUUG conference in Cologne last
week ;-). I thought a bit about the metadata problem that results in the
1 GB limit of ext2fs and ufs filesystems (and theoretically others as well).
I didn't find a solution yet (still pondering over/on the problem), but here
is something that could probably help:
In FreeBSD, softupdates are currently being developed/tested for UFS
filesystems. I'm not aware of the ext{2,3}fs efforts here, but looking
at ReiserFS or other journalled filesystems could be a good idea as well ;-).
If we managed to use a similar approach in the libdiskfs-based servers,
we could probably avoid having to map all metadata in virtual memory.
This is just a speculation; as I still have to read/study the papers and
code of softupdates and journalled filesystems. Anyone else on this list
familiar with this kind of filesystems? Any link appreciated.
The links to softupdates are:
Abstract: http://www.mckusick.com/softdep/
Paper : http://www.ece.cmu.edu/~ganger/papers/CSE-TR-254-95/
Regards,
-Farid.
--
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Multithreading experiences outside of Hurd/Mach
Hi Marcus, as you probably know, the FreeBSD people are trying to multithread their kernel and their experiences are pretty interesting for Hurd/Mach people as well. We can talk offline about specific details, if you're interested. Here's the URL: http://people.FreeBSD.org/~fsmp/SMP/SMP.html Sorry for the noise, guys! -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Linux Binary Compatibility
;/cluster/host11.mynet.net/bin/myprog"); Here, /bin/myprog (on "our" host, that is, the host that calls exec()), gets exec()d on host5's cpu #2, host9's cpu #1 and host11 (using its default scheduler) respectively. Okay, that's enough SF for now ;-). Could someone more knowlegeable in glibc and exec() please point out, what is necessary to do in order to swap linux' glibc to the Hurd's glibc in binaries dynamically linked against linux' glibc? That would be a first step towards binary compatibility. Thanks, -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Linux Binary Compatibility
> > We _could_ use this Lites approach as well in the Hurd, to provide > > binary compatibility to, say, Linux-Binaries. > > My only questions is: Why would we want binary compatability? Every > OS/app that I can think of that used this as a selling feature (OS/2, > Wine, Win95 for Win 3.1 apps) failed miserably at the emulation > (unforseen gotchas!), and tended to fail to attract the attention of > the end users. > > I would prefer to see us focus on the process of building an awesome > OS, and have our *own* major selling points draw people to us. First of all, the world is not perfect. There are plenty of binary applications out there, that don't come with source. Some of them are even popular, e.g. JDK, StarOffice, Maple+Mathematica, Oracle etc... Now you could argument, that the Hurd is supposed to support free (or at least open source) software onlay. Personally, I would even agree with you here, but other users may see it differently. IMHO, FreeBSD's linuxulator is a great selling argument in favor of FreeBSD, opening up more flexibility anyway. I would agree with you, if adding this binary compat feature would slow down everything or even break the overall architecture of the Hurd. I don't consider binary compatibility as a necessary feature of the Hurd, if that would be the price. The point is just, that if it is relative easy to do so, why not try it? Regards, -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Linux Binary Compatibility
> I'm not arguing for Free Software only. One of the things I like best > about us sharing a libc with Linux is that porting *should* be no > harder than a recompile. Part of the Debian/Hurd porters work is to > help remove any recompile barriers from thousands of programs. Agreed. > I feel that by permitting people to run their binaries on our system, > we'll be 'another Linux port'. There will be no reason to mention > "Runs on the Hurd". Ultimately, people will begin to demand that we > do things the way Linux does. GNU's not Unix, but Linux is. GNU > permits us the freedom to do things differently, and hopefully better. Yes, I understand and share your concerns here. Actually, implementing this binary compatibility could be more harmful to the project (by diverting people from recompiling) than beneficial. Hmmm..., that's an interesting perspective. Anyway, I didn't consider the issue from this perspective as I asked about that glibc trick (didn't get a reply yet); just being interested in the technical way to do it. I'll have to read more about ELF and exec() to figure it out. Thanks for the feedback. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
SawMill Multiserver vs. the Hurd
Hello, the following paper describes the SawMill L4-based multiserver that is being developed at Big Blue: http://www.research.ibm.com/sawmill/sigops00.ps AFAIK, Sawmill didn't release any sources (yet?), but some of their (mainly) architecture papers are available. It's quite interesting to compare the Hurd's architecture to Sawmill's, especially considering the differences between Mach and L4. Is someone here involved directly or indirectly with SawMill project? It would be quite interesting to compare the Hurd's and SawMill's architectures, and probably even merge useful ideas. Hmmm... People interested in porting the Hurd to L4 are invited to join the [EMAIL PROTECTED] mailing list. l4-hurd was put on hold some time ago, since we didn't find volunteers with expertise in thread libraries (we need a n:m-multiplexing thread-library for L4), but we should IMHO have a new try at it. Please note that I'm not trying to drag resources away from bug-hurd, but rather looking for Hurd hackers that could help make the Hurd even better ;-). Thanks, -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: how it works: hurd users
> here is something that hopefully helps people to understand how the Hurd > user model works. It is of course far from perfect, not complete, etc etc, > and it is certainly not supposed to be a replacement for proper > documentation (in fact, I don't even think it is adequate as a base for it). > I hope it is useful for developers and people who want to become developers, > and people who can turn this into good documentation, maybe as an addition to > the Hurd info manual. Well done, Marcus. This is exactly the bird's eye view on an important component of the Hurd that developer newbies need to get started. If you would be willing to write more intros about other parts from time to time, that would be great! -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Hurd and glibc
> What is the relationship between the Hurd and glibc? By this I mean, > which version of glibc is appropriate to use when working with the Hurd. > Is the glibc source from Debian the proper one to use? I compiled glibc from savannah and used it with the Hurd recently without problems. I don't know where Marcus gets his glibc sources from when he generates the .deb's. > It seems that awhile back, glibc used to be in the Hurd CVS, but now it > is not. How often are there Hurd specific changes to glibc, and how long > does it take them to make it back to the the Debian source version? Look at the Changelog in the main glibc directory ;-). Pay special attention to sysdeps/hurd, sysdeps/mach etc You'll quickly find out what changes apply to the Hurd. > Is there a list of patches against glibc that need to be maintained for > the Hurd to work properly? No. The current glibc _is_ the actual official C-lib for the Hurd. -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: L4Mach or Refactor Hurd Servers?
that manages low-level [kernel-] IPC handles like port rights and the like? Instead of putting this into buckets, wrapping classes around them etc.., this looks like it really belongs in the stubs. We may need a powerful stub generator [backend] for Mach, that could integrate some of libports? Then again, the stub generator for the L4 port would so something else. I've not made up my mind yet. Anyway, a good and clear separation of Mach-things and the Hurd interface in libports would be very useful. * > that I'm on the l4-hurd list, so perhaps there has been some discussion > there that I haven't seen. But every time someone posts to bug-hurd with > their opinion about the Hurd's relationship to Mach, they speak in > completely vague general terms and never present anything concrete about > the details of the IPC system they'd like to work with, how they would > adapt the Hurd to use it, and what the problems might be. The discussions on l4-hurd currently boils down to this: * the VM semantics of Mach will be met by implementing an l4-based pager task. This pager would probably not use Mach-VM directly, but the improved NetBSD UVM variant. The L4-based pager will have an IPC interface of some kind (as specified in an IDL spec) and can thus be RPCed directly. The preferred way to IPC the pager would be provided by a helper library that will implement the vm_*() calls mentioned above. * the drivers will be implemented in user-level tasks. One possibility that was discussed is to use OSKit drivers directly. This may not be so good, because OSKit links in a lot of other stuff and thus unnecessarily bloats binaries. Another possibility is being investigated by the L4Env group at University of Dresden. They plan to provide a L4 framework, where the sourcecode of current (I think it was 2.2.x, not 2.4.x) Linux drivers could be simply dropped in and where they would build user-level driver tasks. I've not yet looked at this though. As far as the Hurd is concerned, I can imagine that a Mach-like API glue could be written, so that those new drivers can be accessed like Mach devices. * It seems like there is agreement, that L4 IPC will not be used directly but only through an IPC stub generator that could adapt to new revisions of the L4 API. There are two reasons for this: The L4 API is currently being revised and is expected to change in the near future. We have to use existing L4 kernels now, so we can't use a not-yet stabilized new API with the current kernels. Using a stub generator will isolate VK/L4 or the Hurd from such fluctuations. The other obvious reason is that code written in IDL is much more portable. All that is needed is a pair of different stubs, one for Mach, and one for L4. This can be achieved in the stub generator alone, e.g. using two different IDL-generators or an IDL-generator with two different backends (like flick). If you want to have a glimpse on a simplest multi-server OS running on top of L4 and using flick, please look at SC/OS: http://www.l4ka.org/projects/SCOS/ http://i30pc11.ira.uka.de/~kevinelp/sysimpweb/example/dev.html I suppose that the Hurd port will use similar techniques. > As to your specific question, I can't imagine that anything you might call > "L4Mach" would be a worthwhile thing to do from a Hurd perspective. But I > am only guessing what you really have in mind, since you have not been at > all specific. Yes, I agree here. L4Mach will not be something like, say, Lites. We will have to implement some Mach functionality like VM and the drivers, and the Hurd people will have to help us with the wish list above. For the drivers, we'll probably follow the L4Env group's work. -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: L4Mach or Refactor Hurd Servers?
> Apologies for the lack of information. My goal is to build a Hurd system that > can run using an L4 microkernel. I see two basic options for doing this: > > 1) Create a /boot/gnumach.gz that uses L4. No changes to the Hurd code. It would be nice, if it were possible. However, the Mach/L3 work mentioned earlier showed that there is a lot of trouble implementing the whole Mach functionality as an L4 server. This seems much more difficult than L4Linux, but you'll have to ask Michael or Sven if they still see it that way and also why they came to this conclusion. Please Cc: l4-hurd in this case ;) > 2) Supplant /boot/gnumach.gz with an L4 microkernel and rework the Hurd > libraries to use L4 features where they currently use gnumachs'. This would be too much work, and the split between Hurd/Mach and Hurd/L4 would become too wide. Parts of the Hurd should be IMHO rewritten in such a way to avoid things specific to Mach-IPC, putting most of the rest into the realm of a stub generator. therefore: 3) Supplant /boot/gnumach.gz with /boot/l4ka and provide a vk-l4 environment that aims to implement generic mach stuff (vm, devices, simple IPC); at the same time, modifying the Hurd's sources to rely more upon an interchangeable RPC stub generator, dropping Mach-specific IPC stuff as discussed earlier. > I understand what would be required for (1) better, so initially it seems > attractive. However, as you pointed out, I don't see how useful that would be as > a resulting system. I think I will work on (2) and see where I can get to. There are actually two fronts on which we need to work: 1.) From the bottom up, i.e. by writing the VK/L4 environment that we are currently talking about: UVM-Pager, L4Env Device-Framework, Flick or other IDL stub generator. 2.) From the top down, i.e. migrating from MiG to IDL-Flick/Mach3, removing Mach-specific IPC calls etc... [implementing as much as possible from our "wish-list"]. 1. would be done by people willing to play with L4 and low-level system programming in general, in coooperation with L4 hackers at Dresden, Karlsruhe and at UNSW among others. 2. would most likely be done by Hurd/Mach hackers [if we can convice them], in close cooperation with us. Both parts can be started immediately and can proceed in parallel until 1) a basic VK/L4 environment stands, so that we can boot from a disk [device framework must be ready], start up a pager [vm must be ready] and load some initial boot program [that would later load ext2fs and the rest of the Hurd] 2) the Hurd can be compiled w/o MIG, using only flick [or any other portable IDL-stub generator that can produce both Mach and L4 stubs], the glibc sysdeps are adapted to release the Mach dependencies somewhat [most of Mach ain't present in L4 and will have to be redirected to our VK/L4 libraries anyway], VM calls are being exclusively routed through vm_*() calls (no pager tricks), [so that we can plug in our own pager(-library)]... At that point, we'll need to closely work together to adapt both the Hurd sources and the VK/L4 environment to get a fully functional system up and running. > -- Ian -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: OS personalities for Linux
> > The Hurd can run in parallel to itself. If it can run in parallel to other > > OSs depends if those OSs can run on Mach, and if you have a bootloader for them > > that runs in the Hurd. > > If I understood Farid correctly, he ran the Hurd beside Lites. Yes, that's correct. -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: L4Mach or Refactor Hurd Servers?
of the generated stubs into the Hurd codebase (mostly in libports, where they are kept in classes and buckets). > It seems to me that libports marries the Hurd to a Mach style microkernel. Right. > -- Ian -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: L4Mach or Refactor Hurd Servers?
Replying to my own scribblings... ;-) > * VM should be accessed through vm_allocate(), vm_deallocate(), > vm_map(), vm_unmap() _only_. Maybe vm_remap(), later. Add to this vm_protect(), and, very carefully, vm_inherit(). > Please don't meddle with the default-pager directly, unless > this is done through a well-defined interface that we could > emulate/reimplement in an L4-based [UVM-?]pager. -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: slow access to files
Hi Diego, > I've noticed that access to files on Hurd is noticeable slower than using > Linux. For example compiling hurd require a lot of disk access using hurd, > while cross compiling hurd on linux uses few disk access. I'm sure you're not comparing apples and oranges here, though it may seem so at first sight ;-). You're right: the Hurd _is_ currently slower at accessing files, compared to Linux or *BSD. Part of the _perceived_ slowness arises from the very inefficient fork()/exec() syscall emulation in glibc, but this is only visible when accessing a lot of files in multiple processes like in e.g. 'configure' runs (among others). The main reaons for the slowness of the Hurd's file I/O, is that data is actually _copied_ more often than necessary between the clients and the file servers/translators. Just look at the sources of glibc and the hurd, starting e.g. with glibc's write(), its hurd-ish sysdeps, which IPCs the translator, which in turn goes to the storeio etc... That's quite a lot of copying going on. Compared to Linux/BSD's integrated VFS/VM buffer cache, that's extremely inefficient ;-). The unnecessary multiple copying of data would already consume a lot of CPU cycles, but wait, this is even worst than it may seem at first sight: Every single access (e.g. an "atomic" write(2) call) not only induces two context switches [to kernel and back], but a lot more: One IPC to the translator (via Mach), another IPC of the translator to storeio (again via Mach) and then access to the disks etc... [if not cached in storeio]. Add to this the response IPCs etc.. All this consume a lot of CPU cycles as well. Now if the applications use a lot of small read(2)/write(2) calls, you've got a flurry of data copying, IPCs and context switches that is, say one order of magnitude slower than in Linux and *BSD. > The question is: there is some kind of caching on hurd or in gnumach? Can be > useful implementing caching, for example, in the storeio translator? First possible caching is in storeio: Data that is being read from physical devices can be cached in storeio (look at the sources). This is the most important cache when it comes to speed. The next best thing in caching is when the filesystem translator shares memory (with mach's vm_map() call) with its underlying storeio. This would speed up things quite a lot. The problem right now is that there is no memory sharing between normal clients and the filesystem translators. Here, data is simply copied across a costly IPC path, thus wasting a lot of CPU cycles. It would be nice to add a mmap()/munmap() IPC to the translators, so that clients can obtain vm_objects directly linked to, say, storeio's memory space. This way, the clients could change [pages of] a file through direct memory read/writes. If done well, this would be hidden from user programs which will still use read(2)/write(2) calls. glibc's sysdeps would then either IPC the translators or request memory-mapping of [e.g. frequently used?] parts of the file. This change would however break the current design of the Hurd, and I'm not expert enough here to see the ramifications of this choice. > I've also noted that during compiling hurd, there is a lot free memory > avaible, so why don't we use it? Here too, you're right. The reason is the same as said above: we don't have a VFS buffer cache like in Linux/BSD, but just copy the data when available [from client to translator and back]. > Diego Roversi | diegor at maganet.net > | diegor at tiscalinet.it -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
emulating no-senders notifications in L4?
> > Absolutely. No-senders/dead port notification is one of the hardest parts > > to port to a non-mach kernel, like L4. > Please don't talk about these as if they were the same thing. Dead > name notifications are not very important. As said, sorry for the confusion. no-senders was meant. > No senders notifications > *are* important, and the use we make of them is critical in any > Hurd-like system. Could you please point at the files/functions that depend on no-senders notifications? To Mach novices: A no-senders notification is sent by Mach to a task that is having receive-rights on a port X, as soon as the count of outstanding send-rights for port X drops to zero. Or more sloppily: as soon as no thread can send messages to this port anymore (not counting send-once rights). The problem here is that Mach maintains state w.r.t. the number of clients that have send-rights to a port. Under L4, things change a lot, because everything is stateless there. Under L4, every thread can IPC to a "port", provided that this thread knows the appropriate TID (which just happens to be the TASK/THREAD-ID of the thread that is sitting on the receiving end of the IPC). Moreover, L4 doesn't hide the specific TID namespace from clients, as Mach does with its local-only relevant port-numbers. Security issues must be dealt with in user-space, e.g. by the threads that do the actual IPC or, more precisely, that proceed the messages they receive. Put another way: you always have "send-rights" to any "port" that is listening to messages. If you can't figure out a way to avoid no-senders notifications, we'll have to emulate these too :-(. This would be very bad, from a performance point of view. The only solution I'm seeing here right now would go along these lines (somehow): 1. The only entity that is allowed to hand out TIDs (a.k.a ports) to clients will be a user-land port-rights server task. (pr-server). 2. The pr-server will maintain state that is normally located in mach: Not only reference count of send-rights, but also a list of TIDs that got the send-rights (for notification purposes). 3. A client can explicitely relinquish a send-right by notifying the pr-server about it. The pr-server will update its state and notify whoever registered with it for no-senders notifications if necessary. 4. Since there is no way to reliably/synchroneously detect the crash of a potential IPC sender (a client), the pr-server will need to regularly poll the clients that got send-rights. This can be done somewhat like this: 4.1. A thread in the pr-server will regularly wake up and send requests to all threads that got send-rights. [This can be done sequentiall or on a scatter-gather basis, but this is mainly an implementation issue] 4.2. A dedicated thread in every client will respond to the pr-server requests if the client is still there. If the client is not there, 4.1. will detect this. 4.3. pr-server will update its state and send notifications to every client that registered with it, if the sender-count of a port dropped to 0. 5. Clients interested in getting no-senders notifications about a send-right port that they got from pr-server can register with the pr-server (probably as part of the IPC that requested the send-right in the first place [a boolean flag]). If they registered, they'll get no-senders notification as soon as pr-server detects this condition. This is an awkward way to do it, especially because it is not synchroneous. Sure, most of the time, clients will synchroneously relinquish send-rights (case 3.) so we get reasonably quick responses. The problem is with crashing clients etc... The biggest problem however is one of performance. Since IPC performance is so critical, this pr-server stuff adds quite a lot of overhead to a very common operation. This is the reason that it would be very useful to think of other ways in the Hurd itself (if possible). -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: L4Mach or Refactor Hurd Servers?
> > Basically, it proved difficult to emulate the complete Mach API. If you > > want to implement L4Mach, it will most likely provide just a subset of > > Mach, so that we can get the Hurd up and running (in a first step). > Making the Hurd run on L4 should be done by porting it. Making L4 > emulate Mach, in part or in whole, is probably a waste of time. Agreed. > > The most difficult issue is IMO how you want to handle asynch. IPC, > > especially the notifying mechanism. In the Hurd, you need at various > > parts to detect/receive something called "dead port notification". > > Emulating this on top of L4 (with or without the help of a L4Mach > > server) may be difficult, but I'm not sure yet. > > Do you mean dead name notifications, or no-senders notifications? The > former are not so important. The latter are very important. You're right. I meant no-senders, not dead-name notification. Sorry for the confusion. > > This is the most important question regarting the port. If the Hurd had > > been designed with other microkernels in mind, it would have certainly > > been more restrictive on its use of mach-specific IPC-ism. > > We *have* been so restrictive. The need of no-senders is quite > inherent; if you understand what we use them for, it's clear that any > system simply must provide a similar function, whether "asynch" or > not. > > Thomas -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: emulating no-senders notifications in L4?
> > When a task dies, its resources need to be all cleaned up. If it's > > the last task with the right to send to that port, then a no senders > > notification should be sent. If we rely on the task to do so itself, > > then sometimes it will not happen due to task misbehavior. > The general idea in L4 is to have a server which creates and deletes > tasks. This server "owns" the tasks and is the only one allowed to > execute the task_new syscall for them. L4 tries to keep task allocation > policy out of the kernel allowing user apps to replace the task server. > If an application wants to create or delete a task you simply send an > RPC. For L4-HURD I could imagine to have the server sending death-name > notifications. Yes, that is the way to go. The question is how a task is actually terminated. The obvious way is to have a user-level library function like e.g. _exit() RPC the task server, so that the task server reclaims the task, right? -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Hurd on Mach on GNU/Linux (verion 0.0.0)
Hi John, > http://tobeyhutchison.com/jtobey/Hurd/gnumach-otop.tar-0.0.0.bz2 > > What this hopes to be is enough of GNUMach ported to POSIX/Linux to be > able to run the Hurd binaries where they have been sitting on my disk > since the last time I booted them up. Wow, I'm truly impressed! I didn't yet download nor tried it, but will do so on my development NetBSD/x86 box, just to be sure that it really is POSIXish enough for my needs ;) As you've correctly guessed, you're not the only one interested in a user-land mach emulation that permits hacking on the Hurd inside a POSIX (restricted to x86-platforms) system. [I hate frequent rebootings too ;-)] Mach/POSIX seems to provide exactly the benefits that the VK/POSIX scenario is supposed to implement. Since you're implementing Mach rather than the simpler VK, running current Hurd programs would be (hopefully) possible without any changes to the Hurd sources. In the future, I'd prefer that we gradually move away from Mach and put the Hurd sources on top of a simpler VK. If (and when) this transition is made, you could hack on Hurd sources and run them on VK/POSIX on your development POSIX machine and on VK/Mach on top of Mach. People familiar with the VK concept can skip the rest of this mail. On the l4-hurd mailing list, we're discussing the need for and form of a layer between the [micro]kernel and the Hurd that will isolate the Hurd from a specific kernel that it is running on top of. I called this layer VK (virtual kernel). The idea is that the Hurd (and glibc) should use _only_ functions from this layer to access the VK. VK itself will relay those calls either directly to its underlying [micro]kernel or will emulate missing functionality in user-land. Depending on the underlying [micro]kernel, there will be many variants of VK: VK/Mach, VK/L4, VK/POSIX etc... A VK will provide to its users (which could be the Hurd or some other OS personality like user-land Linux, user-land BSD, ...) a uniform set of "system calls". This is somewhat similar to POSIX, which provides a set of system calls to user-land programs. Just like there exist multiple implentations of POSIX kernels (Linux, BSDs,...) there will be multiple implementations of VK (VK/Mach, VK/L4, VK/POSIX...), all providing the same set of system calls to OS personalities (and programs running on bare metal, emmm, bare VK). Concerning the Hurd, a naive approach would suggest that VK system calls be exactly the same set of syscalls than Mach provides. This way, VK/Mach would simply be a set of empty macros and be up and running on Mach right away. Furthermore, the Hurd would not need to be modified to run on top of this simplistic VK. VK/POSIX would then have to emulate as much Mach as possible so that the Hurd can run there. This VK/POSIX would be exactly what gnumach-otop is intended to provide! Unfortunately, setting VK=Mach is not a good idea. If proved very difficult to emulate enough Mach on top of L3 (a precursor of L4). Moreover, and even more importantly, some characteristics of Mach stand in the way of kernels providing faster IPC like L4. If we ended up setting VK=[big subset of]Mach, VK/L4 would be slower than necessary and Hurd/VK/L4 would be even slower than Hurd/VK/Mach or Hurd/Mach. This would defeat the whole purpose of porting the Hurd to L4 in the first place. So VK will need to provide a sufficiently small subset of Mach to be useful at all. This involves changing the Hurd sources to use less mach- specific things that will not be present in VK. We're currently in the process of assessing the Hurd requirements of such a VK and of means to implement VK/L4. Once the set of VK syscalls stabilizes, VK/POSIX (and most likely VK/Mach) could be rather quickly implemented. Then, the Hurd sources will need to be modified to use only this stable set of VK syscalls. Such hacking could be effectively done either on Hurd/VK/Mach or Hurd/VK/POSIX, the latter being what John is intending with gnumach-otop right now. Okay, enough general talk for now and back to hacking... > ps, OTOP means "On Top Of POSIX" but there are a few Linux and i386 > dependencies still in there. > John Tobey <[EMAIL PROTECTED]> -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: mach_port_t vs task_t (really ipc_space_t) in Mach header files
Hi Marcus, > I saw that the defs file have nice specific types like ipc_space_t and > mach_port_name_t, but the C header files almost all have mach_port_t for > them. In the Hurd, we have a typedef for each of these types and keep > them in the header. We even use task_t in proc etc. > > I am now using mach_port_t in mach.texi everywhere (where it is used in the > generated C header file), rather than the more explicit type in the defs > file. But maybe we don't want that? I've stumbled across this problem as I tried to convert some *.defs to omg-idl. Since IDL is a strongly typed interface definition language, keeping the more specific types seemed more sensible in a first try (you could simply typedef those types away to mach_port_t). Two questions: * are the more specific types at least _consistently_ used? I doubt this is the case: a lot of files simply fall back to mach_port_t later * are they really needed for architectural reasons, or, more precisely, for better readability? In the Mach case, I'd guess "maybe no," but on non-Mach VKs, that could well be a different matter. Actually, I didn't find the specific types in the *.defs very helpful for drawing clean lines of abstractions. They seem to have been added as an afterthought, but were propagated to the bulk sources very half-heartedly, if at all. So if you're going to remove them, that would be okay with me (IMHO). At least, as far as _mach.texi_ is concerned, it may be okay, but please remain consistent with Mach headers ;-) What do others think? -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Why GNU Mach is so different?
> Now, I am reading (and studing) all docs that I could find about CMU > Mach UX e US, OSF e Utah Mach . I read old massages from lists too and I > strange that many important stuffs in research and others implementation > (like NORMA IPC, SMP, RT, ports...) are missing in the official > distibution (CVS). Why? Will be need to develop this stuffs again? NORMA IPC Version 1 is currently only present in CMU Mach 3.0 and RTMach. RTMach itself is availabe from NTT/Keio (please look at the-hurd-links.html for the link) as a drop-in port for FreeBSD. Support for NORMAv1 was dropped when the Open Group started to work on NORMAv2. Unfortunately, they never publicly released that code, so you'll have to study their whitepapers and try to reimplement this yourself. The question is rather if you should do so. I did quite a lot of experiments with a cluster of Mach machines running NORMAv1 with XMM; the reason being to continue the development on task migration and load distribution started by Dejan Milojicic. This proved harder that I expected in the first place and after discussing the issue of (Mach-based) distributed memory management with people working in the field; it became clear, that Mach sementics were _still_ too bloated to provide reliable TM+LD support. This was also one of the main reasons for moving research towards L4 and other lighter microkernels. Mach research seems to have "stalled" in the last, say, 5 years, and we've learned quite a lot from the Mach experiment. I wouldn't want to discourage you from diving into Mach; its just that Mach is not at the "bleeding edge" of research anymore (at least not mainstream). > I want to work with distributed systems and clusters until the finish of > my course (college). I know that many work are being done with L4, but > in my understanding, when someone say that L4 is "working in process", I > see in Mach work done with many tests, researches and results waiting to > be improved and used. I wouldn't buy the argument that Mach is finished wether L4 is WiP. RTMach for example is still being actively developed and SMP support is present and maintained in some (alas non-opensourced) Machs. OTOH, L4 is stable enough to be used for real-world experiments: Just look at the L4Linux emulation server, L4-Fiasco, L4Ka(Hazelnut), L4/MIPS etc... kernels. They are all excellent and can be used right now for experiments. The imminent release of the upcoming new L4-API (Version 4) will also contribute to help boost L4-based development further. If you're really interested in clusters, distributed shared memory, transparent cluster-wide IPC, task migration, load distribution, crash resilience and recovery etc..., you may be much better served by using L4 rather than Mach: IPC ist more reliable, since it's not buffered by the kernel (think of crash-recovery of single nodes w.r.t. checkpointing); NORMA-like semantics can be implemented in user-land IPC servers, memory management was always (as in Mach) the domain of user-land pagers, schedulers can also be user-land,... More important though is the small amount of task/thread state that needs to be transferred in the case of task migration. Without ports redirection and all this having to be done in the kernel... More on this, if you're interested. > Others thoughts that I had, are about the Corba (I read something and > nothing more), modules for devices drives (like linux); those things are > better implemented on kernel or is possible on user space? Regarding CORBA: The only part of it that we'll need in the Hurd right now, is a good IDL stub generator that could replace MIG. The path right now looks like we're needing to switch to flick IDL compiler and change the *.defs with *.idl(s). Then, we could use e.g. DICE or IDL4 to generate stubs for L4 instead of Mach. Other CORBA stuff looks currently like unnecessary overhead to me. The dream of uKernel developers is of course to move device drivers outside the ukernel. The idea is to have user-land device driver tasks that will serve interrupts etc... on the one side and requests from an OS entity on the other side. You _can_ write device drivers in userland, both for Mach and for L4 (it's easier for L4). The point is not, that you can do so, but if you could cannibalize e.g. the large Linux driver codebase. One effort to do this was the OSKit which you should really examine more closly. The OSKit is being used both in the oskit-mach effort as well as in the L4 community. Another approach is (still-to-be-released) L4Env environment, where it should be possible to drop the source code of Linux drivers into a framework so that it integrates in the L4 user-land tasks. > I know that some ideas can be wrong... after some mounths trying > contribute to GNU/Hurd, I concluded that more study about OS is > necessary before I try
Re: Why GNU Mach is so different?
> RT. The Hurd is not a real time system. It doesn't make use of RT. The > Hurd runs on RT Mach, though. So you can use the real time extensions in a > Hurd system, but you can't rely on the Hurd servers or the C library to do > any RT'ish things for you. Are the real time changes free? We might > include them by default in the future, if we find someone willing to > port and maintain them. Exactly! > BTW, I guess some stuff was disabled (SMP) when the Linux device driver glue > code was integrated, and never resurrected. With oskit-mach, that part of > the kernel has been cleared up again, and there is hope now to get stuff > like SMP support back into our mach. Agreed. But we'll definitely need some SMP machines to work on. Its quite hard to find SMP motherboads with chipsets compatible to both Linux, FreeBSD-CURRENT (with SMPng) and the yet-to-be-maintained -and-updated Mach SMP code [and maybe a SMP-version of L4 as well] :-(. If there is real interest, we can scan the above mentioned SMP codebases for chipset requirements and post a summary here of what is needed. Someone may have a list of hardware vendors for us too... > > I want to work with distributed systems and clusters until the finish of > > my course (college). I know that many work are being done with L4, but > > in my understanding, when someone say that L4 is "working in process", I > > see in Mach work done with many tests, researches and results waiting to > > be improved and used. > > i think some work can be done here, not only on the kernel level (which you > need), but also in the Hurd servers. I think passing ports over networks > etc can be done in user space on the Hurd (and maybe should). Beside those You want to migrate _Mach_ ports over the net? This essentially means that you have to transfer the message queue, but also leave a forwarding/ redirecting proxy at the old location until all clients have updated their destination portnames. If you move the ports further, you quickly develop a chain of forwarding proxies (which is bad). This is exactly the problem with VM objects in the old Mach VM that was only recently being solved in NetBSD's UVM (by early-collapsing the chains). > technical features you need, there is, for example, the requirement to have > a network-wide unique process id for a task. Thomas calls such a network > of Hurd systems a "collective". I guess if you want to do distributed > systems in a Hurdish way, collectives are the way to go. The concept exists > only in Thomas head, though, so you will have to nag him a bit to tell us > about his ideas. Network-wide unique identifiers like task-IDs, ports, etc... are a nice thing to have. One idea may be to organize all nodes of a collective in a distributed kind of (hurdisch) filesystem. IDs would then be simple paths and could be located with some kind of distributed lookup() functionality: /collective1/ # namespace for collective #1 /collective1/ipc/ # ipc namespace (ports...) /collective1/ipc/machine1/# ipc namespace for machine1 /collective1/ipc/machine1/port1 /collective1/ipc/machine1/port2 ... /collective1/vm/ # namespace for VM objects /collective1/vm/machine1/vmobject1 /collective1/vm/machine2/vmobject25 ... Every member of a collective whould have to provide "translator-like" functionality and register itself with the collective. Or if you prefer, each machine will be "translator", serving its own set of ipc, vm, ... namespaces. Now, _that_ would be hurdish! -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Why GNU Mach is so different?
> > Regarding CORBA: The only part of it that we'll need in the Hurd > > right now, is a good IDL stub generator that could replace MIG. > > The path right now looks like we're needing to switch to flick > > IDL compiler and change the *.defs with *.idl(s). Then, we could > > use e.g. DICE or IDL4 to generate stubs for L4 instead of Mach. > > Other CORBA stuff looks currently like unnecessary overhead to me. > > It's only not a simple thing. First the .defs are really mach-specific > and MiG does a lot of things with ports we have to implement in the > servers if we're going to use CORBA IDL. Yes, that is exactly the problem. _Should_ we implement or duplicate MiG functionality into a stub generator that is designed to generate code for non-Mach systems? I'd prefer that we revisit the dependency of the Hurd code (especially libports) of those MiGisms. This would also contribute to boost performance, since most IPC would then be synchroneous (this is just a guess) and would therefore require less context switches. > Second the IDL compilers are a problem. MiG is no option. Flick has a > few problems (I copypast from the manual): > * Thread Safety: Flick does not generate thread-safe code. If your > application is multithreaded, you will need to provide explicit locks > around the Flick-generated stubs. > * Error Handling: Although the generated stubs generally handle errors > in an appropriate manner, Flick's runtimes may fail an assert or exit > in response to certain critical errors. A future release of Flick will > better address error handling and recovery within the runtimes. > * MIG language: The MIG front end/presentation generator is nearly > complete but does not yet support all of the MIGisms you may love (or > hate). > > DICE and IDL4 are not available yet. However there is going to be some > pressure to release IDL4, more on that later. DICE is available, but doesn't generate stubs for Mach at the moment. So it's not a real option while porting. IDL4 is expected to be released any time soon. Flick does have its drawbacks; there's no doubt about it. However, the main advantage of flick (1.x) at the moment is, that it can generate Mach stubs and L4 stubs. This is really important at this moment. Once the transition to IDL is complete, we could always use other IDL compilers that are better suited to Mach and L4 environments. The biggest challange right now would be to migrate the Hurd to synch. IDLs and drop MiG. BTW, if there are some specific problems with the flick stubs, why not fix them? > L4Env is almost the same as OSKit, I don't see what's special about > it. For me it looks like they are writing an L4 specific OSKit. I'm > also a little bit more critical about the "drop the source code into > the framework and it works" part. I don't think it's that simple, but > maybe I just don't know enough about Linux and L4 drivers. As long as L4Env is not released, we're just speculating here. You may be right here. We just don't know. -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Why GNU Mach is so different?
> > Network-wide unique identifiers like task-IDs, ports, etc... are a > > nice > > thing to have. One idea may be to organize all nodes of a collective > > in a distributed kind of (hurdisch) filesystem. IDs would then be > > simple paths and could be located with some kind of distributed > > lookup() functionality: > > > > /collective1/ # namespace for collective #1 > > /collective1/ipc/ # ipc namespace (ports...) > > /collective1/ipc/machine1/# ipc namespace for machine1 > > /collective1/ipc/machine1/port1 > > /collective1/ipc/machine1/port2 > > ... > > > > /collective1/vm/ # namespace for VM objects > > /collective1/vm/machine1/vmobject1 > > /collective1/vm/machine2/vmobject25 > > ... > > Would not > >/collective1/ # namespace for collective #1 >/collective1/ipc/ # ipc namespace (ports...) >/collective1/ipc/port1 >/collective1/ipc/port2 > > be more useful? It would be useful if you want to blur the distinction between single machines. This may be useful in some cases (e.g. when the machines are set up in a symmetrical way, meaning all machines have roughly the same characteristics), but not in others. Consider the case of some file servers, some compute servers and say, some routers and/or protocol converters. You want to access ports on specific machines for specific tasks. With the flat namespace, you can't easily discover which port belongs to which machine (at least not only by the pathname). Even hybrid settings could be possible: /collective1/compute-servers/ipc/port1 /collective1/compute-servers/ipc/port2 ... /collective1/file-servers/ipc/port1 /collective1/file-servers/ipc/port2 ... where 'compute-servers' and 'file-servers' would designate a group of similar machines which could be treated as a group. Using a flat-namespace would require an extended lookup a.k.a name resolution algorithm to finally map the port to a specific machine. It _could_ be done by the (distributed?) "translator" that serves the names (e.g. by the translator service the /collective1/file-servers hierarchy), but this would be added complexity. -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Why GNU Mach is so different?
> > You want to migrate _Mach_ ports over the net? > Actualy, what I thought of was only port forwarding. Okay, that is the "easy" part, but the problem with the forwarding chains persists. -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Why GNU Mach is so different?
> > Regarding CORBA: The only part of it that we'll need in the Hurd > > right now, is a good IDL stub generator that could replace MIG. > > The path right now looks like we're needing to switch to flick > > IDL compiler and change the *.defs with *.idl(s). Then, we could > > use e.g. DICE or IDL4 to generate stubs for L4 instead of Mach. > > Other CORBA stuff looks currently like unnecessary overhead to me. > > Just my curiosity: Is it difficult to convert CORBA (or DCE) to MiG? > > If that's easy, we could use (such a converter | mig) for Mach and > IDL4 (or DICE) for L4... The problem with MiG is that it does more than just marshalling and unmarshelling the arguments and calling mach_trap(). I doubt that using a mig2idl converter would solve our problems here. IMHO, the canonical way to do this is to switch to synch IPC completely (this is probably even possible with mig) and take care of the few cases where notifications/callbacks are needed. Once this is done, switching to IDL (or any other interface definition language) would be quite easy. I'm not 100% acquainted to the subtleties of MiG though, so please take this with a grain of salt. > Okuji -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Why GNU Mach is so different?
> > Network-wide unique identifiers like task-IDs, ports, etc... are a nice > > thing to have. One idea may be to organize all nodes of a collective > > in a distributed kind of (hurdisch) filesystem. IDs would then be > > simple paths and could be located with some kind of distributed > > lookup() functionality: > > It was always my plan to have a single IP address for a collective. > (The collective might use IP for communication between its component > systems, but those addresses would be entirely internal.) You certainly want to assign a multicast IP address to the collective, right? -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Why GNU Mach is so different?
> > > > Network-wide unique identifiers like task-IDs, ports, etc... are a nice > > > > thing to have. One idea may be to organize all nodes of a collective > > > > in a distributed kind of (hurdisch) filesystem. IDs would then be > > > > simple paths and could be located with some kind of distributed > > > > lookup() functionality: > > > > > > It was always my plan to have a single IP address for a collective. > > > (The collective might use IP for communication between its component > > > systems, but those addresses would be entirely internal.) > > > > You certainly want to assign a multicast IP address to the collective, > > right? > > No, that's not necesary. At least in IPv4, multicast is too uncertain > to rely on. Hmmm... I use multicasting on *BSD boxes very heavily since years and it works flawlessly. Cisco used to have some bugs in their PIM Sparse tree pruning implementation, but they fixed that approx. 9 months ago. I used multicasting accross the public Internet without problems (but alas not so intensively). Of course, I can't say anything about the pfinet IP stack implementation. If that proves to be faulty, it may be a good idea to grab the TCP/IP code from, say, FreeBSD and wrap that into a bsd_pfinet translator. Sure, it will only happen when it is really needed ;-) > But there are other tricks that can work. :) Of course, one can always simulate multicasting or avoid it completely. That is not a big issue. Please tell us more about collectives. That is a very hot topic! -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: PROPOSAL: making liblinux_net library
> > > 1). I propose to move all linux code out of pfinet and make separated > > > library with linux ip stack. > > > > This is not a horrible idea, and I once thought of doing the same > > thing myself. > > What would be *really* nice is a nice library with nice well-defined > and reasonably stable interfaces, that can be used by all of > linux-kernel, hurd-pfinet, maybe even bsd-kernels and random oskit > applications. What Olin Shivers would call a 100%-solution. Look at netgraph(4) in FreeBSD: http://www.FreeBSD.org/cgi/man.cgi?query=netgraph&apropos=0&sektion=4&manpath=FreeBSD+4.4-stable&format=html It looks like an interesting and probably portable way to achieve what you're looking for. > But I'm afraid (without actully having looked deeply into the issues) > that it would be a big job, both technincally and "politically", i.e. > getting various kernel developers to start using it. Sigh... -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: PROPOSAL: making liblinux_net library
> On Wed, Jan 23, 2002 at 05:12:30PM -0500, Neal H Walfield wrote: > > Wrong. The only reliance that um-pppd has on pfinet is a tunnel > > device; everything else is pretty much standard. > > And the tunnel device has all the semantics from the BSD tunnel device, > because that was my reference implementation at that time. We're probably not talking about the same ppp version anymore. The tunnel device in pfinet behaves correctly, but try to compile a recent ppp, e.g. taken ouf of the FreeBSD -STABLE or even -CURRENT tree. Good luck! I'd be really impressed if that worked without Ng*()!! -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: PROPOSAL: making liblinux_net library
> > BTW, a BSD-based pfinet is highly desired, mainly because of
> > um-pppd. Recent changes in the FreeBSD Net/3 (especially the
> > netgraph(4) infrastructure [e.g. ng_pppoe], KAME, ...) influenced
> > 'ppp' so much, that it would be very hard to synchronize FreeBSD ppp
> > with the Hurd version in the forseeable future.
>
> Wrong. The only reliance that um-pppd has on pfinet is a tunnel
> device; everything else is pretty much standard.
>
Really? Here's an example where this is not true (anymore?). In
FreeBSD 4.5RC (-STABLE), last cvsupped 01/20/2001:
farid@bsdevil:/usr/src/usr.sbin/ppp> uname -a
FreeBSD bsdevil.rent-a-wizard.net 4.5-RC FreeBSD 4.5-RC #0: Mon Jan 21 02:26:11 CET
2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MYTOWER i386
farid@bsdevil:/usr/src/usr.sbin/ppp> grep ng_pppoe *
ether.c:#include
ether.c:if (modfind("ng_pppoe") == -1 && ID0kldload("ng_pppoe") == -1) {
ether.c: log_Printf(LogWARN, "kldload: ng_pppoe: %s\n", strerror(errno));
ppp.8:.Xr ng_pppoe 4
ppp.8:.Xr ng_pppoe 4 ,
Here, ether.c uses the ng_pppoe KLD to provide PPPoE support.
Of course, the code for this is only included when:
#if defined(__FreeBSD__) && !defined(NOKLDLOAD)
but this is not always the case. I see a _LOT_ of references to
netgraph(3) Ng*() functions throughout the code.
So it may still be necessary to port Net/3 and netgraph(4) to the
Hurd anyway, if we want to be able to synchronize to the most
recent ppp version, right? Of course, we could rely on the current
um-pppd, but, we'll miss pppoe and other goodies them!
Regards,
-Farid.
--
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: PROPOSAL: making liblinux_net library
> Really? Here's an example where this is not true (anymore?). In > FreeBSD 4.5RC (-STABLE), last cvsupped 01/20/2001: ^ Of course, I meant 01/20/2002 ;-) Sorry about the confusion. -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: PROPOSAL: making liblinux_net library
> > Really? Here's an example where this is not true (anymore?). > > I was referring to this [1] implementation which makes a minimal use > of BSD features -- at least when I ported it. > > [1] http://www.awfulhak.org/ppp.html Okay, that clarifies a lot of things ;-) Regards, -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Thoughts about the new X.2 spec...
ng to understand the L4 IPC model and think of ways to change the current HURD asynch model to a more efficient/streamlined synch. IPC model. Even if you read the X.0 spec before, please read X.2 IPC spec as well! Sure, most of the IPC would be done by a decent code generator that would ideally support IDL as input language. In this case, we would have probably caught most IPC cases between client(libs) and the Hurd servers. The remaining cases could still be handled manually (read: through specially tailored libraries that use the specific IPC semantics of X.2). What are the special cases exactly? Let's (theoretically for now) try to write them in pseudo code using the X.2 generic programming interface. This would be highly instructive! 9: This is especially important w.r.t. pagers, exception handlers, schedulers etc... One example: The initial user-level pager \sigma0 would be queried by OS-personality pagers once to get either the full physical memory (have it mapped/granted in their address spaces) or only a part of it (if two or more OS-Personalities are configured to run side by side). Now we'll "just" have to implement a decent pager for the Hurd that exports the Mach vm_*() semantics or anything else, if we decide to get rid of mach specific stuff a la MOs entirely. I still suggest that we base our work on UVM, but that is not a religious issue anyway. Because L4 supports multiple pagers, I could imagine that we will also have special kinds of persistent threads that register with a persistency pager. Anyway, we're free to use the pager we want for the threads we want. That's a Good Thing(tm). Another thing is that we should consider wether server threads should be allowed to map/grant pages with user data (say e.g. contents of a file[-buffer]) to clients directly, bypassing the global [UVM?] pager. This is possible in L4, with the cooperation of both pager theads associated with the sender and receiver. Mapping pages as part of the IPC between a file translator and a client could already result in heavy optimization compared to the current copying model. Bypassing the global pager would _perhaps_ result in yet faster IPC, but that is not sure. More on this later... Okay, enough hype for now. Please do read the X.2 specs and let us share thoughs about this ONLY on [EMAIL PROTECTED] (no need to bog down bug-hurd with this. This mail is the only announcement to bug-hurd as a friendly HEADS UP). Thanks, -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: GNU/Linux binary compatibility (Was: Re:memory_object_lock_request and memory_object_data_return fnord)
> > might even introduce a security problem. Thus we would need to recompile
> > all programs anyway. I can't see the point of having binary
> > compatiblity then.
>
> If a user just wants to play Quake V or Duke Nukem Forever, he might not
> need to care about PATH_MAX, as these programs will most likely only
> open trusted files.
>
> Then again, if this is all he wants to do, some kind of binary
> compatibility layer might do the job just as well. FreeBSD users claim
> to be quite happily running the GNU/Linux version of Quake III on their
> computers using compatibility libraries.
Quake III runs flawlessly on my FreeBSD 4.5-STABLE box. A lot of other
Linux-only binaries run too, like Maple, Oracle 8i, Java SDK 1.4.0 for
Linux, StarOffice 5.2, RealPlayer, etc... Some Linux binaries run even
_faster_ under FreeBSD than under Linux (e.g. setiathome client for Linux).
Go figure!
They are three aspects of BSD's Linux compatibility:
1. {Free,Open and Net}BSD provide Linux binary compatibility through a
simple trick: They just provide besides their normal ABI the Linux
ABI as well. When a Linux binary generates a syscall() and so a trap,
*BSD takes over and either handles the trap the BSD-way (most of Linux'
syscalls fall under this category) or the trap is redirected to a
Linux-specific kernel module which maintains enough state to implement
the Linux-specific things.
2. The BSD loader can recognize a Linux binary (if it is branded as
Linux ELF, else one can brand that binary manually with brandelf(1)).
Such binaries are then linked against the normal Linux dynamic libs
like glibc etc... Note that there is nothing special about the compat
libraries: they are just the normal Linux libraries. Users can replace
them or add their own linux libraries that would be used instead if
they wish. As soon as, say, glibc calls (linux) syscall(), the trap
handler in 1. takes over.
3. Linux' /proc filesystem differs from BSD's /proc fs. For this
reason, the BSD's implemented a subset of Linux' /proc (called
linprocfs) and mount it e.g. on /usr/compat/linux/proc. The linux
trap handler (more exactly, the VNODE layer) detects calls to /proc
from linux binaries and transparently redirects them to linprocfs.
The main advantage of BSD's Linux compatibility ABI is
a. it exists ;-)
b. it runs as fast as the native BSD ABI
[actually, there is no such thing as a native and an emulated
ABI in BSD. Both BSD and Linux ABIs are first-class citizens]
The main disadvantage of the current implementation of Linux compat
under BSD is
c. it is still uncomplete [e.g. only subset of /proc in linprocfs,
yet enough for most purposes, and some problems with specialized
linux kernel modules (say ALSA...) that have no correspondent
or mappable pendant in BSD].
There are other binary compatibility modes besides Linux. See NetBSD
http://www.netbsd.org/ for good examples of binary compat modes for
a lot of architectures ;)
All in all, binary compatibility is a nice thing to have.
> Oystein
-Farid.
--
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: %gs:0 thread pseudoregister in oskit-mach
Roland, Jeroen, I know this is irrelevant for oskit-mach proper, but it may be interesting to know if you're introducing any dependency in, say, glibc/pthreads: In the L4 V4 spec, Appendix A (x86 Interface), register %gs is used to point to the UTCB of the current thread (read-only). Please see http://l4ka.org/documentation/files/l4-x2.pdf Regards, -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: %gs:0 thread pseudoregister in oskit-mach
Roland McGrath wrote: > > I know this is irrelevant for oskit-mach proper, but it may be > > interesting to know if you're introducing any dependency in, > > say, glibc/pthreads: > > > > In the L4 V4 spec, Appendix A (x86 Interface), register %gs > > is used to point to the UTCB of the current thread (read-only). > > You may need to change that. The %gs:0 word will become part of the > ELF/x86 ABI for TLS support. Huston, we're gonna have a BIG problem! The UTCB is a central information page for L4 userspace threads and it's pretty difficult to find another x86 register that can be used to point to it. Espen, I know the spec can't be changed at this point. Do you see any workaround for this problem? Regards, -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: %gs:0 thread pseudoregister in oskit-mach
> > The UTCB is a central information page for L4 userspace threads > > and it's pretty difficult to find another x86 register that can > > be used to point to it. > > What's wrong with %fs? But anyway, that is fine if the one word at %gs:0 > can be made available for user use. Ideally that word would be writable > (which you could manage along with read-only use by situating the segment > base on a page boundary, one page writable and one not). But the only > thing that would write it is pthreads innards, so it would be workable to > have a system call to set the %gs:0 word for a thread. Hmmm, the L4 X.2 spec only says that %gs:0 points to the UTCB area and that it should be read out. If userspace threads can change %gs:0 without interfering with L4, fine. We could just squirrel %gs:0 away in crt0.c before glibc takes over and changes %gs. BUT, I'm not sure if * %gs:0 can be written to by userspace threads * the L4 API _implementation_ reads %gs:0 afterwards. > I don't know the L4 interfaces, but why not just make this page accessible > at a canonical address accessible from the standard user %ds segment? %ds and other registers are needed for the L4 syscalls. The problem is that especially x86 has so few registers :-( Espen or someone from the L4ka team should comment on this, please. -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: File Share and Sandbox project
access control is limited to the compositions of users > in groups. A user belonging to a group has access privileges You should read the papers of the L4 people who had to struggle with exactly the same kind of authorization and authentication issues. They developed L4 with security in mind and are still refining their security model, even redoing it from scratch in some parts (they dropped the clans and chiefs model for instance). > Goal one: enable simple user configurable file sharing with > granularity, in a user space implementation. Yes, "fileshare" is indeed a very good example. > III. Process Rights Management: Sample application: Confined Email > > Goal two: Implement a secure 'virtual sandbox' for potentially rogue > processes whose authenticity or unverifiability make them a threat to > the user. What would be the fundamental difference between traditional chroot(2) or jail(8) environments and this scenario? Basically, they're the same, aren't they? > V. Related discussions. > > If I have overlooked places where there is or was prior ideas that you > are aware of, I will appreciate being made aware of them. Is the discussion taking place offline or on #hurd? I didn't see anything on bug-hurd as yet. > Time line: My goal is to complete a workable version of the first run > of this translator prior to Jan 1 2003. Good luck! -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Due to budget cuts, light at end of tunnel will be out. --Unknown. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Mach ports use
> To communicate between two translators, is it better to have one > bi-directional port, or to have two mono-directional ports ? What are > the advantages/issues of these both ways ? Which ones allows (in theory) > the highest rate of data transfert ? > I think two ports can be better (it is for network purpose), am I right > ? As far as Hurd/L4 is concerned, mono-directional ports are the only possible alternative. > olivier -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Due to budget cuts, light at end of tunnel will be out. --Unknown. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: [OT]: Hurd microkernel portability.
> > > It tickles to me read things like, "netbsd, the most portable OS in > > > the world", and stuff like that. > > Anything wrong with that? > GNU/Hurd ultimately needs to be 'THE OS'. We can't compromise on that, > can we ?? Why? GNU/Hurd is a great system, and it would be even better if more people worked on it. Yet it has its shortcomings, as we all know. No OS could IMO cover all aspects. Just think of embedded OS(es) (both time-triggered and interrupt-controlled), OSes for SIMD and MIMD architectures, ... Ah, you meant "Desktop/Server OS?". Well... ;-) -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Due to budget cuts, light at end of tunnel will be out. --Unknown. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Design your own Linux-shoes
> Sending "Spam" to Linux-users.=20 > How dumb can these guys be you must be thinking? = > This is like teaching Bill Gates the word "open source" or like having = > sex with Mrs. Tyson. So, before you bomb the hell out of us or instantly = > block all of our IP addresses, please do listen up. We're not as stupid = > as you might think. We, like you, are proud Linuxers ourselves, so how = > could we be? We got your address searching on linux sites and we promise = > we will only use it once. What do you say? Deal? ROTFL! So called "Linuxers" who spam HURD (!) lists, add HTML to double the bandwidth waste, and use X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 sending from: Received: from node1fc5f.a2000.nl ([24.132.252.95] helo=localhost) by gnuftp.gnu.org with esmtp (Exim 4.20) id 19b6YL-0001o4-SY for [EMAIL PROTECTED]; Fri, 11 Jul 2003 18:39:53 -0400 a2000.nl's broadband service. What creeps. Yeah. Proud "linuxers". You've made my day! Please, let's change the posting policy of our lists to subscribers only. I know this has been discussed at length so many times before, yet no-one at gnu.org seems to care. Sorry, this was OT, but I couldn't resist this time. -FH. -- Farid Hajji. http://www.farid-hajji.net/address.html ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Design your own Linux-shoes
> > Please, let's change the posting policy of our lists > > to subscribers only. I know this has been discussed at > > length so many times before, yet no-one at gnu.org seems > > to care. > > No, it's useful for non-subscribers to send messages. That doens't happen so often. If we grep out all known subscribers, what does remain? Are we afraid of losing one or two legitimate mails out of many spams? We can safely assume that people who are interested in the Hurd are also capable of subscribing to a mailing list before posting their queries (especially if automatically asked by mailman or whatever)... > Also some > people have mail configured to send mail from a different > address than their reply address is. Have them subscribe all sending addresses, and eventually filter (or ignore) any duplicates on their side. It is also possible to disable delivery from the mailing list manager to all but one address. > Robert Millan Now getting back in lurker mode... -Farid. -- Farid Hajji. http://www.farid-hajji.net/address.html ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Design your own Linux-shoes
> > > > Please, let's change the posting policy of our lists > > > > to subscribers only. I know this has been discussed at > > > > length so many times before, yet no-one at gnu.org seems > > > > to care. > > > > > > No, it's useful for non-subscribers to send messages. > > > > That doens't happen so often. If we grep out all known > > subscribers, what does remain? > > My messages, for example. They're tagged by mailman as message > from non-subscriber. Yep... :-/ -- Farid Hajji. http://www.farid-hajji.net/address.html ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: creation time as Hurd extension?
> > what about having the creation time of a file as an Hurd extension, which is > > maintained across copies, like the author? > > It seems far more useful than the author bits. Why restricting meta data to a fixed set of attributes? I've read about a (user-)extensible meta-data scheme some years ago in a paper. Unfortunately, I didn't copy that or its reference (arghhh) back then, and I can't find it now :( -- Farid Hajji. http://www.farid-hajji.net/address.html ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: creation time as Hurd extension?
> > Why restricting meta data to a fixed set of attributes? > > I've read about a (user-)extensible meta-data scheme some > > years ago in a paper. Unfortunately, I didn't copy that or > > its reference (arghhh) back then, and I can't find it now :( > > A particular filesystem implementation can have its own extensions and > its own tools to use these extensions -- except that such extensions > are not be available via io_stat (). For instance, ext2 has its own > attributes that can be managed using lsattr or chattr (under GNU/Linux). Sure, but that was not what I'm meaning here. Every FS implementation, including ext2, provides currently a _fixed_ set of attributes/extensions. This set is generally hard coded in inodes. There is no way for a user to attach her own set of meta data to the standard set, because the implementation uses fixed space in the inode (bitmaps etc...) for those attributes. Even ACLs are currently implemented this way in most FS. There is no compelling reason to store extensions directly in inodes. They can be hung off from the inode and stored either in regular or, shall I say, metadata files (think about it: directories are regular files too), or in blocks managed by the file system itself. Of course, the question is how to access these attributes through a special system call. Things like LDAP come to mind, though they are not necessarily the only possible solution. As a quick hack, I could imagine an inode namespace like this: /fs/.inodes/12343 /fs/.inodes/14232 /fs/.inodes/23232 The meta attributes for inode 12343 in /fs would be stored in the meta-file /fs/.inodes/12343, e.g. in LDIF format: cn: blah blah # canonical file name au: author desc: this file is about blah blah desc: more desc. acl: user-x user-y user-z acl: user-a user-b user-c acl: user-m user-n user-k This scheme is extensible, because users are free to add/modify attributes, just like they would in an LDAP directory. Of course, not every attribute would be user-accessible/modifiable, so those meta data files would only be accessed through syscalls (just like directories in Unix can only be written to by the FS implementation). Well, that's just an idea (and not the one in that paper). > Ludovic. -- Farid Hajji. http://www.farid-hajji.net/address.html ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Hurd Sourcecode Cross Reference [was:Re: Hurd advocacy?]
> Hi All, > Thanks for the Source code browser link. Does any body has idea if a > simmilar software exists to browse local (offline) source code > repositories ? Why won't you use GLOBAL? >From the package description: "GLOBAL is a source code tag system that works the same way across diverse environments. Supported languages are C, C++, Yacc, Java, PHP and Assembly. You can locate a specified function in the source files and move there easily. It is useful for hacking a large project containing many subdirectories, many '#ifdef' and many main() functions, like MH, X or BSD kernel." WWW: http://www.gnu.org/software/global/ You can convert every set of source files to HTML with the program htags (which is part of the global distribution). > Thanks. > Ashish -- Farid Hajji. http://www.farid-hajji.net/address.html ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Hurd Sourcecode Cross Reference [was:Re: Hurd advocacy?]
> > Hi All, > > Thanks for the Source code browser link. Does any body has idea if a > > simmilar software exists to browse local (offline) source code > > repositories ? > > Why won't you use GLOBAL? > WWW: http://www.gnu.org/software/global/ See also: http://www.gnu.org/software/global/links.html subsection "Source code browsing Tools" > > Thanks. > > Ashish -- Farid Hajji. http://www.farid-hajji.net/address.html ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: "network administrator" in GNU/Hurd
Replying to my own post: > Actually, it would be nice to port the jail(8) mechanism to the Hurd. We > could perhaps even rename it to matrix(8)... ;-) Anybody volunteering? If someone is interested in this, I'd suggest to start experimenting with sub-Hurds (you can start a new set of Hurd servers from within the Hurd). In a nutshell, a sub hurd _can_ provide a virtualized environment, similar to jail(8), when configured properly. There are some issues like synchronizing access to devices which need to be addressed, but this looks like a manageable task. Once problems with sub-Hurd are sorted out, a jail(2) syscall and command tools like FreeBSD's could be added to glibc as well. -- Farid Hajji. http://www.farid-hajji.net/address.html ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: L4??
> Hello from Gregg C Levine > What is, the L4? About all I know about that term, is that it's a > Lagrange point in space. I vaguely have heard about it, someplace, in > relationship to the base HURD project, but that's all. L4 is a modern microkernel, optimized for IPC performance. It is actively developed and supported by the research community. A port of the Hurd to L4 is under way (currently at the design phase). The specific L4 implementation that will be used is L4Ka::Pistachio, available here: http://l4ka.org/projects/pistachio/ Most discussions on the Hurd/L4 port are taking place on the [EMAIL PROTECTED] mailing list. Archives: http://mail.gnu.org/pipermail/l4-hurd/ -- Farid Hajji. http://www.farid-hajji.net/address.html ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: disallow direct inclussion of
> > > I think we should disallow direct inclusion of in Glibc, any > > > comments? > > > > This is not an issue related to the Hurd at all. If you think that this > > should be done, for whatever reason, you need to talk to the glibc > > maintainers. > > I know. But this seriously affects portability to non-Linux-based systems, > which includes GNU/Hurd. > I'm really sick of encountering programs that break because of arbitrarily > including stuff. Today I just recieved a patch for a program I > maintain that adds an #include on just to get the PATH_MAX > macro. I'm going mad with this kind of stuff. > > If people really want Linux-specific features, let them define _USE_LINUX or > something like that. Same problem for BSD porters. This is _really_ annoying for every non-Linux porter/maintainer out there. I'd strongly support such a move; perhaps starting with a deprecation #warn-ing, and later changing this to a hard #error. > Robert Millan -- Farid Hajji. http://www.farid-hajji.net/address.html ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: disallow direct inclussion of
> > I think we should disallow direct inclusion of in Glibc, any > > comments? > There don't exist any headers in glibc, they come from > Linux. Perhaps glibc should provide its own wrappers which would spew out warnings, but still #include the real linux headers (I assume something from /usr/src/linux/include/*.h or whatever) anyway? > Jeroen Dekkers -- Farid Hajji. http://www.farid-hajji.net/address.html ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: on what kernel is the Hurd running presently .
> is it mach 4 or l4 .can some body give me the details >about the exact state of l4-Hurd combination . Hurd/L4 is a project that aims to port the Hurd from GNU Mach to the L4 microkernel. To be more precise, to the L4Ka::Pistachio implementation of L4: http://l4ka.org/projects/pistachio/ Please refer to the [EMAIL PROTECTED] mailing list, archived here: http://mail.gnu.org/pipermail/l4-hurd -- Farid Hajji. http://www.farid-hajji.net/address.html ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
