Hi,
this patch changes the interfaces of the bottom handler to return error
values. To keep it simple, for now every old function is changed to return 0.
The actual error checking in devio.c for example can then be added later.
This is also desirable because I am not sure if term can really cope
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> On Thu, Jan 31, 2002 at 03:00:37PM -0800, Thomas Bushnell, BSG wrote:
> > > I can make such requests, but how do I find out that the carrier really has
> > > been established? (Also, it would not allow servers to implement the open
> > > behaviour b
On Thu, Jan 31, 2002 at 03:00:37PM -0800, Thomas Bushnell, BSG wrote:
> > I can make such requests, but how do I find out that the carrier really has
> > been established? (Also, it would not allow servers to implement the open
> > behaviour but not the tiocl bit mangling).
>
> Yeah, you are cor
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> I can make such requests, but how do I find out that the carrier really has
> been established? (Also, it would not allow servers to implement the open
> behaviour but not the tiocl bit mangling).
Yeah, you are correct here. You could assert DTR w
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> Ok. Now, you avoided to answer what is the better approximation in case
> the underlying file supports tiocoutq. npending_output, the queue_size
> returned by tiocoutq, or the sum of both?
You should certainly include npending_output. If tiocout
Roland McGrath <[EMAIL PROTECTED]> writes:
> But anyway, I think you can just control DTR directly like other modem
> lines with TIOCM*.
Except that we don't actually support those right now. :)
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> Do I use a third thread for assert_dtr? If I need to assert the dtr, the
> only strategy I can think of is to open in blocking mode. However, if I use
> synchronous RPC, this is better done in a seperate thread. I don't know how
> to assert the dt
On Thu, Jan 31, 2002 at 02:11:23PM -0500, Roland McGrath wrote:
> > Do I use a third thread for assert_dtr? If I need to assert the dtr, the
> > only strategy I can think of is to open in blocking mode. However, if I use
> > synchronous RPC, this is better done in a seperate thread. I don't kno
> Well, ok, so I can probably put this into the reader loop, but then I
> finally have to learn about interruptible RPCs, as I will have to interrupt
> a blocking read then. ;)
This is necessary for your plan to work at all. The underlying file will
in fact be open as long as there is a pending
On Thu, Jan 31, 2002 at 02:11:23PM -0500, Roland McGrath wrote:
> > Do I use a third thread for assert_dtr? If I need to assert the dtr, the
> > only strategy I can think of is to open in blocking mode. However, if I use
> > synchronous RPC, this is better done in a seperate thread. I don't kno
On Wed, Jan 30, 2002 at 12:32:17PM -0700, Jon Arney wrote:
> In __hurd_file_name_lookup_retry, there seems to be a test for recursion
> in the form of:
>
> switch (doretry)
> {
> case FS_RETRY_REAUTH:
> if (err = reauthenticate (*result))
> return err;
Èç¹ûÄú»òÄúµÄÇ×ÊôÅóÓÑ»¼ÓÐÉöÔಡÇëµÇ¼£º
´Èº½Éö²¡ÍøÕ¾£¨cnsb.info£©
½«´øÄúÍÑÀ벡ħ¿àº£
Èç¹ûÄú»òÄúµÄÇ×ÊôÅóÓÑ»¼ÓÐÈý²æÉñ¾Í´ÇëµÇ¼£º
Èý²æÉñ¾Í´ÍøÕ¾£¨chsbyy.com£©
> Do I use a third thread for assert_dtr? If I need to assert the dtr, the
> only strategy I can think of is to open in blocking mode. However, if I use
> synchronous RPC, this is better done in a seperate thread. I don't know how
> to assert the dtr otherwise.
You don't need an additional thr
Marcus Brinkmann wrote:
>
> It should definitely fail with ELOOP.
I aggree.
>
> The bug is probably in glibc/sysdeps/mach/hurd/access.c, which is the
> implementation of access() on the Hurd. That would be a good place to
> start your research. (Could also be in the file name lookup itself,
On Wed, Jan 30, 2002 at 02:52:30PM -0800, Thomas Bushnell, BSG wrote:
> I think this is a very good strategy. Mach RPCs can be split into
> asynchronous IPC calls, but this is not true of most RPC systems that
> we might want to port to. So it's ok to take advantage of the Mach
> semantics in Ma
On Wed, Jan 30, 2002 at 10:21:26AM -0700, Jon Arney wrote:
> The upshot of the whole
> thing is that if you call access() on a recursive link,
> the /hurd/auth process goes nuts!
> I think this is a really neat feature of the 'access()' call and the
> behavior of the /hurd/auth daemon, but not ev
Hi.
In the course of "building my own" hurd system from the
sources, I came across an interesting "feature" of the
access() call. It happened accidentally, and took me a little
while to figure out what caused it, but I have an easily
reproducable test-case for it. The upshot of the whole
thing i
On Thu, Jan 31, 2002 at 01:03:33AM -0800, Thomas Bushnell, BSG wrote:
> A race should always be avoided if it makes a bug. But there may be a
> way to avoid it without select.
Well, the only other idea I have beside io_select would be to have another
look just around the io_write that can be use
--- "Thomas Bushnell, BSG" <[EMAIL PROTECTED]> wrote:
> James Morrison <[EMAIL PROTECTED]> writes:
>
> > Before I get to the patch, here is an interesting error:
> >
> > Fatal error, aborting.
> > load average of 17 is too high
>
> From where?
>
I tried to run cvs diff -u and I got that erro
Title: ++ Topcine Mail ++
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Title: »õ ÆäÀÌÁö 1
¾È³çÇϼ¼¿ä.
ºÒ¾¦ ¸ÞÀÏÀ» µå·Á¼ ¹Ì¾ÈÇÕ´Ï´Ù. ÁÁÀº CD°¡ ÀÖ¾î¼ ¼Ò°³ µå¸±±î ÇÕ´Ï´Ù. Ȥ ºÒÄèÇÏ¼Ì´Ù¸é »ç°ú µå¸³´Ï´Ù.
±ÍÇÏÀÇ ÀÌ ¸ÞÀÏ ÀÌ¿Ü¿¡´Â ¾î¶°ÇÑ Á¤º¸µµ °¡Áö°í ÀÖÁö ¾Ê½À´Ï´Ù. ´Ü 1ȸ ¹ß¼ÛÇÏ¸ç ¼ö½Å °ÅºÎ¸¦ ÇÏ½Ç ¶§´Â ¹Ý¼ÛÇÏ¿©
Áֽøé Àý´ë ¹ß¼ÛµÇ´Â ÀÏÀÌ ¾ø½À´Ï´Ù
Á¤º¸Åë½ÅºÎ ±Ç°í »çÇ׿¡ ÀÇ°Å Á¦¸ñ¿¡ [±¤°í]¶ó°í Ç¥±âÇÑ
±¤°í ¸ÞÀÏÀÔ´Ï´Ù.
ÀÛ³â ÇÑÇØ ÀÏÀÌ Á¦´ë·Î ¾ÊÇ®¸®¼Ì´øºÐ, ´ä´äÇÑ »ç¿¬ÀÌ ÀÖÀ¸¼Ì´øºÐ!!
¿ª¼úÀΰú »ó´ãÇغ¸½Ê½Ã¿ä ºÐ¸í ´äÀÌ
ÀÖ½À´Ï´Ù
ÅäÁ¤ºñ°á, ¼Ó±ÃÇÕ °Ñ±ÃÇÕ, »ç¾÷¿î, ½ÂÁø¿î, ÁøÇпî, °Ç°¿î,
ÀÛ¸í, ÅÃÀÏ, º°ÀÚ¸®Á¡, dz¼öÁö¸®, ¾ÖÁ¤¿î, »ç¶û¿î
James Morrison <[EMAIL PROTECTED]> writes:
> Before I get to the patch, here is an interesting error:
>
> Fatal error, aborting.
> load average of 17 is too high
>From where?
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/lis
James Morrison <[EMAIL PROTECTED]> writes:
> - err = __dir_mkfile (dir, O_WRONLY, 0644, &new);
> + err = __dir_mkfile (dir, O_CREAT|O_WRITE, 0644, &new);
Hrm.
O_WRITE is surely better than O_WRONLY, but they are equal in fact.
And the implementation of dir-mkfile.c in libdiskfs always turn
Neal H Walfield <[EMAIL PROTECTED]> writes:
> Is there any reason that we are using the older from
> libc/sysdeps/generic/netinet/ip.h and not one similar to the one that
> Linux uses in sysdeps/unix/sysv/linux/netinet/ip.h. The reason that I
> ask is that we do not have definitions of either `
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> On Wed, Jan 30, 2002 at 02:52:30PM -0800, Thomas Bushnell, BSG wrote:
> > The Right Thing is surely two separate threads. I'm not sure that
> > select is really necessary at all however.
>
> I have stumbled upon an obscure race where it helps. I
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> The issue I am talking about is implementing pending_output_size correctly,
> which should return the number of bytes pending for output. The problem
> exists only for ioports that have the tiocoutq capability. Because we don't
> know if the underl
27 matches
Mail list logo
