Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> The obvious difference is what happens to data that is available in the
> underlying file while CREAD is turned off. Both, devio and ptyio discard
> such data, while in your design it would be delayed until CREAD is enabled.
> I couldn't find out wh
Roland McGrath <[EMAIL PROTECTED]> writes:
> I think you should discard data when CREAD is clear. I also think a change
> in CREAD state should be passed down with a tioctl call as for modem
> control bits. When (eventually, with new interfaces) this is passed all
> the way down to the device d
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> An easier question: devio.c uses the _request and _reply functions,
> eg asynchronous I/O, which would work very well in the hurdio case,
> too. However, for hurdio, I think it would work equally well to
> have a reader and a writer thread, which do
Of interest to us too.
--- Begin Message ---
The combination IEEE POSIX 1003.1-2001 / Single UNIX
Specification Version
3 is now online at the following URL:
http://www.UNIX-systems.org/version3/online.html
This is for free (as in Beer, but not as in Liberty, as IEEE and
Open Group
copyr
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> Can you expand on that? In particular, I would be grateful if you could
> clarify "cancellation". Cancellation in pthreads is requesting the
> termination of a thread, where I neither see how that is important in the
> Hurd, nor what is missing for
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> It was my impression that the devio handler tried to detect a blocking write
> and would interpret it as carrier off. So my question is along that line,
> but for the hurdio handler. What I am asking about is the semantics between
> the hurdio node
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> On Tue, Dec 18, 2001 at 01:36:47PM -0800, Thomas Bushnell, BSG wrote:
> > > error_t (*assert_dtr) (void);
> >
> > Turn on DTR.
> >
> > > void (*desert_dtr) (void);
> >
> > Tu
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> There is no king's path into the Hurd. In particular, there is nothing
> (yet) that will feed you everything you need to know spoon-by-spoon.
The colloquial English expressions here are "royal road" and "spoon
feed you everything".
__
Roland McGrath <[EMAIL PROTECTED]> writes:
> I haven't checked your code, but make sure you call mach_msg_destroy
> on the bogon so that ports and ool memory get freed.
No, that would be a mistake. The caller is responsible for doing that
if the message is not recognized by any demuxer. Since
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> I remember reading about this in the TODO list etc. Are there any concrete
> other unrobustnesses you remember?
There are a jillion. The filesystem basically assumes that it's
talking to the kernel. If it's not, then the user could be bollixing
t
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> Neal reported this bug to me a while ago. If you send an invalid message (a
> message with an unhandled msgid) to a pager, it will miss out on this msg id
> and the seqno stuff doesn't catch up anymore. The result is a deadlock
> waiting for this m
Galchin Vasili <[EMAIL PROTECTED]> writes:
> Are there some example "clients" (test programs) of the various
> libstore servers??
Huh? Say more exactly what you mean. There are many programs in the
Hurd source that use libstore (the best simple example being the
storeio server).
___
Galchin Vasili <[EMAIL PROTECTED]> writes:
> I know that the storeio (directory storeio) server uses the
> libstore library, but what kind of store does this server actually
> manage?
Whatever type is asked for on the command line.
___
Bug-hurd
Gordon Matzigkeit <[EMAIL PROTECTED]> writes:
> One could always try removing the definition, and see what breaks when
> turtle catches up.
I think that's what we should do (at that point it becomes a release
engineering issue which Marcus is in the best position to handle).
___
Roland McGrath <[EMAIL PROTECTED]> writes:
> 1998-06-01 Gordon Matzigkeit <[EMAIL PROTECTED]>
>
> * sysdeps/mach/hurd/errlist.c (sys_nerr, _sys_nerr): Make weak
> aliases for _hurd_nerr, for programs that don't use sys_errlist,
> but need sys_err.
First, that's a typo; it sh
Peter Novodvorsky <[EMAIL PROTECTED]> writes:
> So what can be done -- is to make some good interface in this
> library. It should generic enough for being applied to BSD ip stack
> too.
I don't think you understood what I wrote.
The details of what the Linux network stack expects from the rest
Wolfgang Jährling <[EMAIL PROTECTED]> writes:
> It allocates an array of sys_nerr elements (the sys_nerr in glibc on
> GNU/Hurd is 119) and tries to store an object for each E* constant in
> one of those elements, but uses the actual value of the constant as
> offset. However, it doesn't crash wh
Peter Novodvorsky <[EMAIL PROTECTED]> writes:
> 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.
However, two things block the idea:
1) The amount of Hurd speci
Galchin Vasili <[EMAIL PROTECTED]> writes:
> In addition to the storeio server, what servers use the libstore
> library, i.e. what other servers "store" servers, in the source tree?
Look in the Makefiles and see!
___
Bug-hurd mailing list
[EMAIL
Galchin Vasili <[EMAIL PROTECTED]> writes:
>I sent these questions a few days ago. I am sorry if this
>a repeat, but my email box was full so I was afraid I lost
>your reply.
Go look at the mailing list archives.
___
Bug-hurd mailing list
Galchin Vasili <[EMAIL PROTECTED]> writes:
> 1) Regarding "stuct store_class", is the idea to provide
> different store personalities, e.g. gunzip, stripe, part, etc?
Yes. The list of currently supported types is in ;
see the STORAGE_* macros.
> 2) It seems that we have an
Farid Hajji <[EMAIL PROTECTED]> writes:
> 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
Neal H Walfield <[EMAIL PROTECTED]> writes:
> Thomas had an idea one day when he was driving down a highway that
> would fix the protocol to not require that the translator itself hold
> a reference to the underlying node, however, he has not yet shared it.
I'm not sure I know any way to avoid t
Farid Hajji <[EMAIL PROTECTED]> writes:
> > > 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
Farid Hajji <[EMAIL PROTECTED]> writes:
> > 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
"Jamie Gennis" <[EMAIL PROTECTED]> writes:
> I'm new to the hurd and have been browsing around the source tree
> trying to become familiar with how things work in there. I came
> across an "/* XXX should work! */" in trans/null.c's S_io_map() and
> thought this might be a good place to start cod
Ondrej Hurt <[EMAIL PROTECTED]> writes:
> The exception handler thread must be reliable i.e. in some trusted
> task so we can count on it that it releases resources like port
> rights and the failing task gets killed.
As I understand it, this is not true. The exception handler thread
does not n
Neal H Walfield <[EMAIL PROTECTED]> writes:
> I disagree; libdiskfs should be used.
Quite right.
> Embracing the Unix philosophy, the implementation should be as lazy as
> possible, i.e. it should wait until the very last minute to actually
> fill in the data structures rather than doing all of
Espen Skoglund <[EMAIL PROTECTED]> writes:
> If the handler doesn't do
> so the task will merely loop on generating exception, but this is not
> much different from a task going into an endless programmed loop.
Except that traditionally in Unix such tasks get blown away with
SIGILL, and we shoul
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> All input parity checking is done by term itself, and the device
> should just do none (or at least provide a way to turn it off).
Oh, things aren't quite right here yet.
First, note that the arg to input_character is a full int
Roland McGrath <[EMAIL PROTECTED]> writes:
> > This is all true. The problem is that Mach's device interface sucks,
>
> What interface would you like for this (parity and break reception)? It
> seems to me that either you need to have a general way to return
> out-of-band exceptional data even
Diego Roversi <[EMAIL PROTECTED]> writes:
> I need some help in debugging a pager. I'm trying to implement a cache in
> libstore and I modified the dev_read e dev_write function, but they are used
> to serve the page foults. The problem is that the translator died with a
> SIGSEGV the first tim
Jean Wolter <[EMAIL PROTECTED]> writes:
> Sure you would have to contact the owner of the port to transfer a
> send right. How often does this happen? I assume it happens in a fork()
> scenario. And the main question is: Does Hurd actually use the
> possibility to transfer receive rights?
Occasi
Ondrej Hurt <[EMAIL PROTECTED]> writes:
> > And a task can not die violently since if it raises an exception this
> > exception is delivered to an exception handler thread which can handle
> > this situation.
>
> The exception handler can get stuck itself somewhere and can ignore
> exception IPC
[EMAIL PROTECTED] (Niels Möller) writes:
> A side effect is that the receiver gets the power to unilaterally
> revoke any send right of its choice. This may be natural, but I'm not
> sure the receiver has that power in Mach.
In Mach, the owner of the receive right can destroy all the extant
sen
[EMAIL PROTECTED] (Niels Möller) writes:
> I believe this class of "simple" rpc:s is what matters for
> performance.
I'm not so sure of that. One critical cases are dir_lookup (which
makes transfers of ports both ways). But it's hard to say for sure
without some instrumentation.
Roland McGrath <[EMAIL PROTECTED]> writes:
> What's questionable to me is some of the funny modes like IGNBRK/BRKINT and
> PARMRK. I guess parity can just be done in term, but it seems desireable
> to pass it down. I think we don't pass it down now in devio because the
> Mach drivers do bogus s
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> > The pty interface does also not handle START and STOP. It stores
> > the state in flags, but it does not make use of it in any way.
>
> That's a bug.
There should be no bug here. Output happens under the control of
p
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> For reference, here is the structure that defines the bottom half.
> For example, there is suspend_physical_output() which supposedly implements
> STOP, and start_output(), which resumes it (but does other things as well).
First, the canonical imple
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> The mach terminal device interface is also used for the console device,
> although it of course does not implement any of the status calls. This is
> why STOP (^S) and START (^Q) don't work.
See below for the strategy for the fix.
> The pty interf
Roland McGrath <[EMAIL PROTECTED]> writes:
> It looks to me like it not only echoes the VDISCARD character, but
> processes it for input. Your change is not right for the second-press
> case, and I think with or without that change it's still wrong to process
> the character below.
Yeah; we don
Roland McGrath <[EMAIL PROTECTED]> writes:
> A really useful test would be someone were to port a useful program like
> make to use posix_spawn in place of fork + exec and do some real-world
> tests (compiles and such) using that.
The three programs that I would most strongly suggest for this
tr
Jordi Mallach <[EMAIL PROTECTED]> writes:
> signal_init()
> - Unconditionally disable VDSUSP if it exists, stops ^Y
> suspending nano on the Hurd.
>
> Can you tell us if this is {the,a} correct fix? I can attach the patch
> if you want. The fix is applied to nano 1.1.4-1.diff.gz
Jordi Mallach <[EMAIL PROTECTED]> writes:
> Under the hurd, pressing ^Y inside nano sends a SIGSTOP, when it should
> just go back one page in the editor. Under Linux it's ok, and only ^Z
> suspends the application when it's ran with the "-z" flag.
>
> Neal says maybe nano isn't ignoring SIGSTOP
Roland McGrath <[EMAIL PROTECTED]> writes:
> I don't know any reason to expect problems from an older e2fsprogs.
There have been various small format changes.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Moritz Schulte <[EMAIL PROTECTED]> writes:
> Hi, hmm, is there anything wrong with that patch? Please tell me if
> that is the case, so that I can fix it.
Um, well, the behavior you see is certainly inconsistent. But one
problem here is that the user-level behavior is *always* supposed to
be to
Moritz Schulte <[EMAIL PROTECTED]> writes:
> Hi,
>
> 2001-12-03 Moritz Schulte <[EMAIL PROTECTED]>
>
> * libdiskfs/dir-lookup.c (diskfs_S_dir_lookup): Don't forget
> the trailing slash when looking up absolute symlinks.
>
> --- dir-lookup.c.orig Mon Dec 3 17:35:09 2001
> +++
Jeff Bailey <[EMAIL PROTECTED]> writes:
> In file included from ../sysdeps/mach/hurd/uname.c:21:
> ../hurd/hurd.h: In function `__hurd_fail':
> ../hurd/hurd.h:71: warning: deprecated use of label at end of compound statement
I have no objection to your patch, but since when was this syntax
"depr
"Bruno A. C. Ferreira" <[EMAIL PROTECTED]> writes:
> When I try to list devices in /dev, hurd creates a process related to the
> device listed.
This is not a bug.
> if I list all the directory, I have lots of processes running, and
> the system becomes extremely slow (because I have only 24M
[EMAIL PROTECTED] (Niels Möller) writes:
> I don't understand all the details of HURD_PORT_USE, like the struct
> hurd_userlink argument that is passed to _hurd_port_get and
> _hurd_port_free, or what information, besides a mach_port_t, is stored
> in a struct hurd_port.
The userlink argument is
Daniel Wagner <[EMAIL PROTECTED]> writes:
> I have a question about the kmsg. Is the datastructer holding all kmsg is
> double linked circular list? I'm asking this, because I can't see it
> with gdb. For example following ikm_next and then comparing with
> the value of ikm_prev seems never to ma
Roland McGrath <[EMAIL PROTECTED]> writes:
> > This is a bug. I have attached a patch. Could you give it a try and
> > see if the bug shows up again (I have never actually seen it on my
> > system)?
>
> I think your fix is wrong. The allocation ought to have already happened
> in pager_unlock
[EMAIL PROTECTED] (Niels Möller) writes:
> 1. Has anybody thought about partial delegation of networking? Does
>that make sense at all?
I have some vague ideas. I think it does make sense, but making it
work seems hard. But if someone prods me, then I can describe my
vague ideas.
> 3. Is
Roland McGrath <[EMAIL PROTECTED]> writes:
> I think the principle of least astonishment dictates that the default
> behavior of existing tools match what they do on existing systems.
> That is, S_ISDIR should be the usual test applied by find and the
> like. I for one will be annoyed if I do "f
--- Begin Message ---
Apparently even some people who work on the Hurd don't know this:
The following are all correct:
The Hurd -- referring to the server suit
The GNU Hurd -- referring to the server suite; same as "the Hurd."
GNU/Hurd -- A complete operating
Diego Roversi <[EMAIL PROTECTED]> writes:
> Hello,
>
> I was studing the gnumach sources and I found the following interface:
>
> routine device_read(
> device : device_t;
> sreplyport reply_port : reply_port_t;
> in mode: dev_mode
[EMAIL PROTECTED] (Niels Möller) writes:
> This sounds a lot like having a mach-port-server that handles all ipc.
> Is that the way to go? How efficiently can the extra redirection be
> handled in L4?
>
> If we go in this direction, there's no real use of any L4-security;
> the only mechanism th
Roland McGrath <[EMAIL PROTECTED]> writes:
> I have found tags in the generated stubs useful sometimes. The old
> code gives you that, if you want to do make TAGS in a build
> directory. We could do that in the configured case. But I don't
> really care.
I think it's actually pretty important
I don't understand exactly what is so horrible about building the .d
files.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Farid Hajji <[EMAIL PROTECTED]> writes:
> Could you please point at the files/functions that depend on
> no-senders notifications?
First, why we need them:
We need to allow file servers (and other servers too) to deallocate
resources when there will be no further sends to a given port. In the
Farid Hajji <[EMAIL PROTECTED]> writes:
> 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. No senders notifications
*a
Farid Hajji <[EMAIL PROTECTED]> writes:
> 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 don
[EMAIL PROTECTED] (Niels Möller) writes:
> Farid Hajji <[EMAIL PROTECTED]> writes:
>
> > 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.
Something should be done with the referenced file.
--- Begin Message ---
Hi,
Is the HURD still developed? I'm asking because the last version seems
http://www.gnu.org/prep/tasks.hurd.html
rather old - the version of the file dates back to 1997.
Thanks,
Adam
--- End Message ---
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> I have this buggy patch here to get mmap() working on nfs.
> Simply apply it, compile nfs and try to mmap a file from it. For me, the
> computer locks solid :) but hey, your mileage may vary. I don't know how
> much time I will have to debug this i
Roland McGrath <[EMAIL PROTECTED]> writes:
> Of course, I also want to thank you again for working
> on the port. It's very exciting!
Ditto!
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Neal H Walfield <[EMAIL PROTECTED]> writes:
> > Implementing that you how suggested would be more or less a rewrite..
>
> Although admittedly, it is an excellent approach.
Well, that remains to be seen. But it is the reason for having the
directory notification RPC's at all. (And also so that
Moritz Schulte <[EMAIL PROTECTED]> writes:
> Implementing that you how suggested would be more or less a rewrite..
Not every filesystem is even able to implement the directory
notification RPC's, so the kind of strategy you're using will still be
necessary for those cases.
_
Moritz Schulte <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
>
> > But that's not so bad. It doesn't mean checking every single entry
> > in both directories; it means checking only those elements which are
> > duplica
Moritz Schulte <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
>
> > Why is it not sufficient to add up the link counts of the shadowed
> > directories (compensating for the -2 term) and use that?
>
> In the case where we have file
Moritz Schulte <[EMAIL PROTECTED]> writes:
> Actually i cared about the performance aspect. If there are shadowed
> directories, which contain _many_ entries and the user simply looks up
> that directory in shadowfs, shadowfs would have to first read _all_
> the directory entries of _all_ of the
Roland McGrath <[EMAIL PROTECTED]> writes:
> Note, however, that this optimization in find will quite totally break the
> filesystem semantics presented by translators set on regular files. That
> is, a translator set on a regular file may well report S_IFDIR and so a
> find ought to treat it as
Roland McGrath <[EMAIL PROTECTED]> writes:
> By my reading of 1003.1-1996, st_nlink should be "the number of directory
> entries that refer to the file". In a case like this, I think it's pretty
> open to interpretation what constitutes a directory entry; there always
> might be extra entries in
Neal H Walfield <[EMAIL PROTECTED]> writes:
> > Why is this not sufficient? This is how every other shared library
> > dependency works.
>
> I was just under the impression that a stub was the right thing to do
> in this case. I am drawing this conclusion from what I have seen in
> libc. Cons
Neal H Walfield <[EMAIL PROTECTED]> writes:
> We have two scenarios: the Hurd with the parted support or without.
> The case we are looking at now is without parted support and how to
> fail gracefully.
> ...
> This is, of course, all moot. No application will use
> store_part_create directly.
Roland McGrath <[EMAIL PROTECTED]> writes:
> > I was thinking this code might be triggered by a user who requested a
> > store_part on the command line to, say, ext2fs. Is that incorrect?
>
> If the hurd is compiled without libparted, then the "part" store type will
> be completely absent, and
Roland McGrath <[EMAIL PROTECTED]> writes:
> Hmm, I think I prefer the status quo. In a program that wants to use it,
> you can write an autoconf test for store_part_create, or use #pragma weak
> if you want a runtime test.
>
> If we have stub function, I think ENOSYS is the right error for it
Neal H Walfield <[EMAIL PROTECTED]> writes:
> The correct solution, would appear to be to return EINVAL if libparted
> is not available. This patch does that:
I think this is almost right... but the error shouldn't be EINVAL. A
user shouldn't get EINVAL just because he requests a feature that
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> Documentation is not built by default. You have to go into the doc
> directory and type "make" to get the info manual and "make mach.ps" to get
> the PostScript version.
IIRC the coding standards say that you should build docs by default,
and also
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> MiG doesn't know unsigned short, so I am afraid that I have to use int.
> The conversion from signed shorts to unsigned shorts is implementation
> defined (or can raise a signal even), so I am out of luck here (unless we
> forbid ports higher than 7
Roland McGrath <[EMAIL PROTECTED]> writes:
> One annoyance that's not really a problem in practice is the inheritance
> (or lack thereof). The Linux `ioperm' model applies to all threads in the
> process (I think) and is preserved across exec (so the documentation says).
> Conversely i386_io_por
"Jacques A. Vidrine" <[EMAIL PROTECTED]> writes:
> Much like comparing the hostname to pathnames, this is an
> apples-to-oranges comparison. Besides, since the system can define
> HOST_NAME_MAX to be any value larger than _POSIX_HOST_NAME_MAX, there
> is no arbitrary limit. As
"Jacques A. Vidrine" <[EMAIL PROTECTED]> writes:
> Are referring to the fact that I would prefer to use a manifest
> constant versus sysconf or looping until a fit is found? Clearly I
> don't think that is an inferior solution, but rather a practical one.
My point is that you are will
"Jacques A. Vidrine" <[EMAIL PROTECTED]> writes:
> If the Hurd will not define MAXHOSTNAMELEN nor HOST_NAME_MAX, then
> indeed there really isn't a good choice. We'd have to use sysconf or
> _POSIX_HOST_NAME_MAX or what we `know' _POSIX_HOST_NAME_MAX to be.
> I think it's a pity.
You s
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> And Thomas doesn't live in Wales, UK, where we notice:
>
> llanfairpwllgwyngyllgogerychwyrndrobwantysiliogogogoch.co.uk
So I knew about the name of Llanfair, but I saw this and said "is that
real?" So I typed (well, cut-and-pasted):
ping lla
"Jacques A. Vidrine" <[EMAIL PROTECTED]> writes:
> OTOH I don't think that an arbitrarily long hostname makes much
> sense.
Really? Have you seen proposals for handling internet growth?
Hostnames are already getting longer and longer. I was once at
"unmvax". Then that became "unmvax.unm.edu".
> --- "Jacques A. Vidrine" <[EMAIL PROTECTED]> wrote:
> > Regardless, the next version of POSIX specifies HOST_NAME_MAX. We
> > should probably be using HOST_NAME_MAX instead of MAXHOSTNAMELEN
> > in the Heimdal sources, or at least do something such as
Note that no system is required to defin
Roland McGrath <[EMAIL PROTECTED]> writes:
> There are probably a few weird hacks that rely on true port polymorphism.
> But most of the uses can be described as interface subtyping (e.g. file_t
> and socket_t are subtypes of io_t).
The auth server, for example, hands ports around, and they are
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> the default pager in serverboot (also used by mach-defpager) is still using
> the legacy interfaces memory_object_set_attributes() and
> memory_object_data_write() to set the ready attribute and receive data from
> the kernel. The newer documentatio
[EMAIL PROTECTED] (Niels Möller) writes:
> Except for strtok... That strtok is used at all in the linux kernel is
> a bug. This was discussed by tytso and some other kernel people over
> lunch at the Erlangen Linux-Kongress some months ago, and the
> conclusion was that the broken strtok interfac
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> I suggest to add strpbrk to the allowed symbols to be taken from glibc, and
> remove the strpbrk definition in the glue code. Thinking about it, we
> should probably remove the strstr, strspn, strtok from the glue code as
> well, and just take them
Neal H Walfield <[EMAIL PROTECTED]> writes:
> > When 'tar' saves a translator, it must also save the file or
> > directory underlying the translator, in case the translator wants
> > to access it when run. The underlying node can be opened with
> > O_NOTRANS.
>
> Do not forget, translators mayb
Roland McGrath <[EMAIL PROTECTED]> writes:
> proc_getexecdata and proc_setexecdata both seem to be totally broken.
> It seems like they have never actually been called.
Surely true.
> I think the only correct thing for proc_getexecdata to do is add a user ref
> to each port and then set *portsp
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> We can talk about this for the Hurd (I think we can do fine with a small
> interface change), but at least in the dynamic linker there has to be a
> recursive lock (there is a XXX in the code for that, we will deadlock on the
> second invocation. Bu
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> In the fully unlocked state, RL->locking_thread is MACH_PORT_NULL.
> How can this match mach_thread_self() of thread 1?
Oh, I take it back. Hrm, it appears that your implementation is fine
after all sorry! :-/
I do still think that using recur
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> On Thu, Jul 05, 2001 at 08:57:15AM -0700, Thomas Bushnell, BSG wrote:
> > Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> >
> > > We agreed, in an inspiring coordinated coding effort, on the following
> >
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> The C library needs recursive locks for the dynamic linker (loading object
> files at run time), and they might be quite useful in libraries, too
> (for better modularization).
Incidentally, it is my opinion that recursive locks don't improve
modula
You want something like:
struct recursive_lock
{
spin_lock_t guard;
int count;
thread_t owner;
mutex_t lock;
};
"guard" protects "count" and "owner", and it looks like this:
lock:
spin_lock (guard)
if (not owned)
assert (count == 0)
owner = me
mutex_lock (lock)
if (
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> We agreed, in an inspiring coordinated coding effort, on the following
> implementation (thanks to Johannes, Neal, Moshe and Rene):
No, that still has a race condition as follows. We begin in the fully
unlocked state.
THREAD 1
[EMAIL PROTECTED] (Niels Möller) writes:
> I think a "recursive mutex" usually refers to a lock that keeps track
> of an owner and a count.
Well, that's what I usually think too. :) But it isn't close to what
the posted functions do. :)
___
Bug-hur
501 - 600 of 686 matches
Mail list logo
