> Quite true, but what if dn_set_mtime is set before the test, and set again
> immediately after it? Then it would be cleared, although the time value
> stored in the timespec would be a bit out of date (as the mapped time is
> read out before the test). Is this something to care about?
Not at al
On Sat, Dec 02, 2000 at 09:04:07PM -0500, Roland McGrath wrote:
> Once the test program exits, the only references that can be held are those
> in other processes or in pfinet itself. What you should do is watch the
> no-senders notification arrive in pfinet when the port is deallocated, and
> se
Your message dated Sun, 3 Dec 2000 06:09:50 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Bug#78524: hurd: pfinet(?) doesn't release bind'ed sockets
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not
On Sat, Dec 02, 2000 at 11:32:56PM -0500, Roland McGrath wrote:
> > > It matters to understand whether or not that code is going to
> > > eventually call set_node_times before it matters that the mtime update
> > > be reflected. If so, then it doesn't matter whether that mtime update
> > > happen
> On Thu, Nov 23, 2000 at 10:34:53PM -0500, Roland McGrath wrote:
> > The first thing to figure out is what the code path looks like that reaches
> > getblk when it sets dn_set_mtime there (I think it should be
> > pager_unlock_page that is doing it, but you should check).
>
> pager_unlock_page a
On Thu, Nov 23, 2000 at 10:34:53PM -0500, Roland McGrath wrote:
> The first thing to figure out is what the code path looks like that reaches
> getblk when it sets dn_set_mtime there (I think it should be
> pager_unlock_page that is doing it, but you should check).
pager_unlock_page and diskfs_gr
Once the test program exits, the only references that can be held are those
in other processes or in pfinet itself. What you should do is watch the
no-senders notification arrive in pfinet when the port is deallocated, and
see it do the deref. See if there is an internal reference still there
fr
On Sat, Dec 02, 2000 at 06:56:10PM -0600, Daniel E Baumann wrote:
> > > ioctl(s, SIOCGIFFLAGS, &ifr);
> >
> > We have this, but ifr isn't initialized yet! You need to set the name.
> > Also, the second argument is a struct ifreq **, while you need a struct
> > ifreq *. But if you change ifr as a
On Fri, Dec 01, 2000 at 08:24:26PM +0100, [EMAIL PROTECTED] wrote:
> Run nfsd, interrupt it with ^C and try to run it again. It will complain
> with EADDRINUSE. That's the same problem that prevents restarting X. Killing
> pfinet let's you start it again.
I have attached a small test program, whi
On Saturday 02 December 2000 13:52, Marcus Brinkmann wrote:
> On Sat, Dec 02, 2000 at 12:31:27PM -0600, Daniel E Baumann wrote:
> > I have writen the function to create an iface startuct in PPP using
> > several SIOC* ioctl glibc calls. This is the first time I've used this so
> > I am posting it
On Sat, Dec 02, 2000 at 12:31:27PM -0600, Daniel E Baumann wrote:
> I have writen the function to create an iface startuct in PPP using several
> SIOC* ioctl glibc calls. This is the first time I've used this so I am
> posting it for inspection, comments and all that.
> struct ifreq *ifr;
Yo
On Sat, Dec 02, 2000 at 12:31:27PM -0600, Daniel E Baumann wrote:
> I have writen the function to create an iface startuct in PPP using several
> SIOC* ioctl glibc calls. This is the first time I've used this so I am
> posting it for inspection, comments and all that. Also, is it ok to reuse the
I have writen the function to create an iface startuct in PPP using several
SIOC* ioctl glibc calls. This is the first time I've used this so I am
posting it for inspection, comments and all that. Also, is it ok to reuse the
same ifreq struct in the ioctl calls or should I declare one for each
Title:
[¿À°øÆûǪ]´Â ¼ÒÇüÄÞǪ·¹»þ ¹× ¼ÒÇüÁø°øÆßǪÀÇ ´ë¸í»çÀÔ´Ï´Ù.
www.okongcomp.com
www.okongcomp.com
±×´ë·Î ȸ½ÅÇÏ¿© ÁÖ½Ã¸é ´ÙÀ½ºÎÅÍ ¸ÞÀÏÀÌ °¡Áö ¾Ê½À´Ï´Ù.
°¨»ç ÇÕ´Ï´Ù
14 matches
Mail list logo
