|
|One nice feature would also be to be able to define aliases of certain
|devices, such as cdrom, modem, etc... I suppose these could get handled
|in rc/rc.conf. Also, I really like the idea of being able to create a
|'limited' devfs mount for a chroot'd environment.
Or via a symlink.
* Nigel Roles <[EMAIL PROTECTED]> [000716 22:11] wrote:
> I am getting strange behaviour with rfork(RFMEM) on a ~2 week old
> kernel. The following code illustrates it. For all the world, the
> stack appears to be shareable after the fork. This is clearly wrong,
> since pid was at some point diffe
Panic over, #include solved that. You learn something new every day.
No pun intended.
Apologies for offtopicness. 50 lines of "I will look on deja next time".
Dave :)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
I am getting strange behaviour with rfork(RFMEM) on a ~2 week old
kernel. The following code illustrates it. For all the world, the
stack appears to be shareable after the fork. This is clearly wrong,
since pid was at some point different in parent and child for them
to take the right case.
I'm s
On Saturday, July 15, 2000, Adrian Chadd wrote:
> Ok, how about you, phk and julian throw up a list of what devfs should do?
> I am forming some ideas on how to solve the namespace and device cloning
> issues, we might make some forward work on this finally? :-)
I'm not Boris, phk or Julian, b
Possibly off topic, but here goes.
I'm trying to use placement new with gcc 2.95.2 on FBSD4.0-Release and can't
get it to go with an error:
:11: too many arguments to function `void * operator new(unsigned
int)'
Disclaimer: I've never tried to use placement new before, but I've RTFM'd
fairly he
This is a great idea. We need a good, well drawn out description of
what DEVFS is supposed to accomplish and how we'd like it to work. I
will be glad to help out, and perhaps we can get some movement on this.
Personally, I'd like to see DEVFS completely replace the current system
of nodes in /dev.
Matt Dillon wrote:
> Committers who mess with VOP_LOOKUP (docs or otherwise), and make
> a mistake, are automatically pardoned due to the fact that VOP_LOOKUP
> is massively convoluted and messy that it has been known to be mistaken
> for a turkish artichoke at times.
*rofl*
I'
:PR 18593 says that VOP_LOOKUP is not a 'VFS entry point', so like a fool
:I believed it and committed the manpage diff within it. :-(
:
:All the other VOP* manual pages just say "entry point", but
:VOP_LOOKUP(9) said "VFS entry point", the patch changed that to be
:consistent with the rest. Can
On Sun, Jul 16, 2000 at 04:31:25PM -0500, Joe Greco wrote:
> I was disappointed to find out that Mouse Systems seems to be out of
> business.
>
> Has anyone hacked up a Sun optical mouse to work with FreeBSD?
>
> The electronics shouldn't be difficult, but I was wondering if someone had
> hacks
I was disappointed to find out that Mouse Systems seems to be out of
business.
Has anyone hacked up a Sun optical mouse to work with FreeBSD?
The electronics shouldn't be difficult, but I was wondering if someone had
hacks to make moused understand the Sun mouse protocol. I seem to recall
it as
Poul-Henning Kamp <[EMAIL PROTECTED]> writes:
> In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wri
> tes:
>
> >So what does everyone think? Is it suitable to add a read only
> >sysctl 'machdep.apm_powerstate' that reports either AC, nn%,
> >or N/A ? Or should the format be numeric (999 = AC,
I've been trying to get the CITRUS project's i18n stuff to build
within a buildworld, and I've run into this bootstrapping problem:
Locales have to be built with the new mklocale because the source
files use new keywords. Because of structure changes and new types
the new mklocale requires the n
Thus spake Bill Fumerola ([EMAIL PROTECTED]):
> > > > PS. No, it's not something stupid like file flags or something.
> > > No, it was something even stupider. Completely ignore this.
> > Oh, come on now, tell us the details! :-)
> It involves this running in another window:
> [hawk-billf] $ whil
Poul-Henning Kamp wrote:
>
> In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wri
> tes:
>
> >So what does everyone think? Is it suitable to add a read only
> >sysctl 'machdep.apm_powerstate' that reports either AC, nn%,
> >or N/A ? Or should the format be numeric (999 = AC, <=100 = battery %,
I had a similar problem once when I changed the processor on
my motherboard from a 486 to a 586. I recompiled the kernel
but I also got those page faults. I asked on these newsgroups
and people suggested the processor was broken. Then I tried
config -r (well I didn't know the -r option so I did
In message <[EMAIL PROTECTED]> Maxime Henrion writes:
: Of course, I did a make depend !
: I think that if config could be dangerous this way, -r should be its default
: behaviour.
No. I've done literally 1000's of kernel builds and have never, ever
had a problem with config's output that would
The problem is that I _DID_ a make depend after the config -r, and this haven't
prevent me to get a kernel which panic'ed.
Larry Rosenman wrote:
> config without the -r reminds you to run a make depend.
>
> Larry
> > Warner Losh wrote:
> >
> > > In message <[EMAIL PROTECTED]> Maxime Henrion
Warner Losh wrote:
> In message <[EMAIL PROTECTED]> Maxime Henrion writes:
> : But after rebooting on this new kernel, I had a page fault before
> : any kernel message :/ Is there anything to check in order to know if I
> : can use a config instead of a config -r ? If using a config without t
In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wri
tes:
>So what does everyone think? Is it suitable to add a read only
>sysctl 'machdep.apm_powerstate' that reports either AC, nn%,
>or N/A ? Or should the format be numeric (999 = AC, <=100 = battery %,
>-1 = N/A)? Or should we not bother? :-)
On Tue, 11 Jul 2000, Kenneth D. Merry wrote:
> > Is Adaptec aic-7892 and 7899 160/m SCSI support in the pipeline to be
> > worked on? aka, has adaptec released any info to those FreeBSD team
> > members who work on the SCSI drivers? Is it possible that maybe within the
> > next 4 months 160/m sup
21 matches
Mail list logo
