> Do you mean that in fact the system comprehensively locates every
> device the first time any device is opened?
In effect, yes.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
> Ok, well then that works certainly. :) I wish there was a solution
> to the harder problem that's always bugged me though. (Dynamic
> probing of hardware at runtime.)
I'm sure there is. But it's not very interesting to me to think about the
details much until we are actually implementing som
Roland McGrath <[EMAIL PROTECTED]> writes:
> > Do you mean that in fact the system comprehensively locates every
> > device the first time any device is opened?
>
> In effect, yes.
Ok, well then that works certainly. :) I wish there was a solution
to the harder problem that's always bugged me
On Fri, Nov 08, 2002 at 10:15:51PM -0500, Roland McGrath wrote:
> > Ok, I can try to find out where the references come from.
>
> Please do.
ds_notify does a dev_port_lookup that acuires a reference. This reference
is not released. So when the last user goes away, and the notification is
sent,
I think the first problem is just some sketchy interactions between gdb and
the kernel's own fault handling. Try picking different spots for your
breakpoints and for where you try to step/next; sometimes you need to set a
bkpt at a later likely spot and continue past a chunk instead of trying to
s
> I didn't update the io bitmap offset at all task switches. I only covered
> stack_handoff and not switch_context. I don't really understand what each
> is used for, but it's quite obvious that it is needed in both and testing
> verified the following change:
stack_handoff is for a context swit
On Sun, Nov 10, 2002 at 12:51:50AM +0100, Daniel Wagner wrote:
> Good news. The pcmcia patch I made for OSKit seems to work, of course
> including some bugs. The patches for OSKit and gnumach are here [1].
Cool! Congratulations, this is really good news.
> I have two major problems found so far
Roland McGrath <[EMAIL PROTECTED]> writes:
> > Hrm. Sure, that's fine for the main hard disk.
>
> You missed the point. The probe is recursive.
Hrm, maybe I'm being misled by the use of "probe". I usually take
"probe for X" to mean "hunt around for X until you find it". Is there
a differen
Good news. The pcmcia patch I made for OSKit seems to work, of course
including some bugs. The patches for OSKit and gnumach are here [1].
I have two major problems found so far. First the hda geometry scan
will _only_ work if the console output goes over the serial line.
Booting without any atta
Patch #642 has been updated.
Project:
Category: None
Status: Open
Summary: simple nfs cleanups
---
For more info, visit:
http://savannah.gnu.org/patch/?func=detailpatch&patch_id=642&group_id=30
__
> Hrm. Sure, that's fine for the main hard disk.
You missed the point. The probe is recursive.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
On Fri, Nov 08, 2002 at 10:15:51PM -0500, Roland McGrath wrote:
> > Another serious bug is that my I/O permission stuff is not working properly.
> > There seems to be a race of some sort.
>
> In that case you really want to put a bkpt at i386_exception or suchlike
> and find exactly what is happen
Hi,
I was cleaning up my home directory and found an old patch. So I updated
the patch, took out some bad stuff andhere it is.. I tested this by attaching
the translator to a node, and doing an ls on the attached filesystem.
The clean ups are fairly obvious, I've mostly only added some m
Jeff Bailey <[EMAIL PROTECTED]> writes:
> It's questionable that they should be artificially hidden in the first
> place, but hey. =)
The purpose of /sbin is not to "hide" anything, but to avoid
cluttering users' command namespace with commands they can't usefully
ever use.
___
On Sat, 2002-11-09 at 12:35, Robert Millan wrote:
> do you mean that someday we eventualy won't need /sbin at all? if that's
> the case i don't mind working the problem around by adding /sbin to PATH
I think that's a nice long term ideal. As soon as you take the idea
that users are gods of their
On Sat, Nov 09, 2002 at 10:04:41AM -0500, Jeff Bailey wrote:
>
> I think I see two potential solutions to this:
>
> 1) /sbin should be added to every users path on i386-gnu systems. The
> concept of a binary that is completely unusable for regular users is
> almost unheard of for us. (The only
Hi!
Sorry for the delay.
On Wed, Nov 06, 2002 at 06:24:28PM +0100, Marcus Brinkmann wrote:
> So what is the TERM setting when you run the ncurses client, and what TERM
> setting is actually needed in the terminal you are running the telnet
> session in? Which size does the terminal have you run
17 matches
Mail list logo
