On Sun, Sep 24, 2000, Adrian Chadd wrote:
> On Sun, Sep 24, 2000, Kris Kennaway wrote:
>
> > > The trouble is that some of the FS strings have spaces in their filenames.
> > > This might confuse a few people.
> >
> > How about mapping spaces to '_' characters - I doubt it would cause an
ith.
Comments and suggestions would definitely be appreciated.
http://people.freebsd.org/~msmith/acpica-bsd-20001002.tar.gz
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
to be opponents, rather bec
eally great!! I didn't think we can have ACPICA
kernel so earlier.
> Comments and suggestions would definitely be appreciated.
>
> http://people.freebsd.org/~msmith/acpica-bsd-20001002.tar.gz
OK, I have a patch for AcpiOsSleep and AcpiOsSleepUsec which I was
involed in recent
Trying to compile the ircII port, it crashes with:
===> Building for ircii-4.4X
cc -I. -I/usr/ports/irc/ircII/work/ircii-4.4X/include -O -pipe -DHAVE_CONFIG_H -c
/usr/ports/irc/ircII/work/ircii-4.4X/source/alias.c
In file included from /usr/include/sys/queue.h:40,
from /usr/in
Hi,
On Mon, Oct 02, 2000 at 12:06:18PM +0200, Poul-Henning Kamp wrote:
> This is because there is a file called "struct.h" in the ircII distribution.
>
> The addition of #include to looks a bit unsettling
> to me: A sys/* file shouldn't reference a /usr/include file I think ?
>
> Is the corr
In message <[EMAIL PROTECTED]>, Jeremy Lea writes:
>> Is the correct thing not to mv to , create
>> a which just pulls in and have
>> #include ?
>
>This breaks several other ports (like BitchX).
I think this breaks all IRC's which are cloned from the same origin :-)
--
Poul-Henning Kamp
On Sun, 24 Sep 2000, Motomichi Matsuzaki wrote:
> This is very stable for usual operation.
> I hope this will be merged into the tree.
I'll take a look at it. I think I've got the beginnings of an EISA
attachment.
--
| Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD |
| [
> >This breaks several other ports (like BitchX).
>
> I think this breaks all IRC's which are cloned from the same origin :-)
I'm still looking for the downside to this. ;-)
- Jordan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Mon, Oct 02, 2000 at 10:10:39AM -0700, Jordan Hubbard wrote:
> > >This breaks several other ports (like BitchX).
> >
> > I think this breaks all IRC's which are cloned from the same origin :-)
>
> I'm still looking for the downside to this. ;-)
'HEY!' ;P
Greetz, Peter
--
dataloss networks
after cvsup and make world today i want to investigate why my notebook cant reboot.
but i am really
new to the source of freebsd. can one tell me where to look?
i can shutdown fine with shutdown -h now till the system writes "press any key to
reboot".
when pressing the key the screen gets immed
In message <[EMAIL PROTECTED]> Chain Lee writes:
: PC-CARD IDE hard disk and compact flash card support is broken
: in recent 5.0-CURRENT. Does anyone have an idea what the problem is?
:
: Please copy reply to me. I don't subscribe to the 'current' mailing list.
They are? Hmmm, I'll have to loo
On Sun, Oct 01, 2000 at 12:14:25PM -0700, Mike Smith wrote:
> Er, this is probably the wrong fix. It sounds like the kernel 'callout'
> structure is ending up visible in userland, which it shouldn't.
The build was broken by the inclusion of in
sys/sys/mbuf.h rev 1.56. includes sys/sys/proc.h
The build was silently broken by AMD including previously.
It wasn't exposed until recently. The correct fix was still to not
include anywhere in AMD (or anywhere else in userland for
that matter).
> On Sun, Oct 01, 2000 at 12:14:25PM -0700, Mike Smith wrote:
> > Er, this is probably the
On Mon, Oct 02, 2000 at 02:24:12PM -0700, Mike Smith wrote:
>
> The build was silently broken by AMD including previously.
> It wasn't exposed until recently. The correct fix was still to not
> include anywhere in AMD (or anywhere else in userland for
> that matter).
Yes I know. I was tr
I would like to change the outputformat of mtree(8) to be more
systematic and machine-readable.
The changes amount to:
make "extra" and "missing" attributes in the output
rather than prefixes which can be confused with filenames.
Don't do the "run-in" of the first attri
< said:
> make "extra" and "missing" attributes in the output
> rather than prefixes which can be confused with filenames.
> Don't do the "run-in" of the first attribute with a short
> filename
This looks like a good change, but while you're there:
> size
In message <[EMAIL PROTECTED]>, Garrett Wollman write
s:
>< said:
>
>> make "extra" and "missing" attributes in the output
>> rather than prefixes which can be confused with filenames.
>
>> Don't do the "run-in" of the first attribute with a short
>> filename
>
>This looks like
he chap at Intel that's been
answering my mails) has just joined acpi-jp (G'day!).
> > Comments and suggestions would definitely be appreciated.
> >
> > http://people.freebsd.org/~msmith/acpica-bsd-20001002.tar.gz
>
> OK, I have a patch for AcpiOsSleep and
> >This is still very obscure; I'd like to see:
> >
> > size (was 1234, should be 5678)
> > cksum (was 42424242, should be 69696969)
> >
> >...so that it's clear what the meaning of the numbers is.
>
> In that case I think I would like to loose the ',' also.
While you're
On Tue, Oct 03, 2000 at 10:46:56AM +1000, Greg Black wrote:
> > > size (was 1234, should be 5678)
> > > cksum (was 42424242, should be 69696969)
> > >
> > >...so that it's clear what the meaning of the numbers is.
> >
> > In that case I think I would like to loose the ',' als
> > >This is still very obscure; I'd like to see:
> > >
> > > size (was 1234, should be 5678)
> > > cksum (was 42424242, should be 69696969)
> > >
> > >...so that it's clear what the meaning of the numbers is.
> >
> > In that case I think I would like to loose the ',' also.
>
> > > >This is still very obscure; I'd like to see:
> > > >
> > > > size (was 1234, should be 5678)
> > > > cksum (was 42424242, should be 69696969)
> > > >
> > > >...so that it's clear what the meaning of the numbers is.
> > >
> > > In that case I think I would like to loose the
On Sat, 30 Sep 2000, Tony Johnson wrote:
> I must admit that I have been less then tactful about this thread. I
> apologize for this. This is my last response to this because once again
> this has gone on far too long.
>
> As far as this response goes. I sense "selective reading." I never sa
On Mon, 2 Oct 2000, Jordan Hubbard wrote:
> > >This breaks several other ports (like BitchX).
> >
> > I think this breaks all IRC's which are cloned from the same origin :-)
>
> I'm still looking for the downside to this. ;-)
>
Well *some* of us still use ircII, however I've successfully compi
On Mon, 2 Oct 2000, Poul-Henning Kamp wrote:
> Trying to compile the ircII port, it crashes with:
>
> ===> Building for ircii-4.4X
> cc -I. -I/usr/ports/irc/ircII/work/ircii-4.4X/include -O -pipe -DHAVE_CONFIG_H -c
>/usr/ports/irc/ircII/work/ircii-4.4X/source/alias.c
> In file included from /u
I've had a persistent (but minor) problem building -current kernels
for a while. I was hoping someone had a fix before taking time to
figure out exactly what was broken myself. Basically, the build goes:
linking kernel
textdata bss dec hex filename
1869802 297944 2299408 44671
I stared at the bpf code some last week, and determined that the
extra make_dev() was in bpf's open() method in the non-devfs
case. As such, I have a rather simple patch. However, I don't
like a driver having to be aware of devfs. Does anyone have any
other (preferably cleaner) ways to fix this
I submitted a PR on this a few weeks ago.
See: http://www.FreeBSD.org/cgi/query-pr.cgi?pr=21391 for comments
from phk.
On Mon, 2 Oct 2000, John Baldwin wrote:
> I stared at the bpf code some last week, and determined that the
> extra make_dev() was in bpf's open() method in the non-devfs
> case
On 03-Oct-00 Tony Fleisher wrote:
> I submitted a PR on this a few weeks ago.
>
> See: http://www.FreeBSD.org/cgi/query-pr.cgi?pr=21391 for comments
> from phk.
Hmm, well your patch would break in the non-DEVFS case. In the non-DEVFS
case, open() still needs to call make_dev(), but I'm eager t
Yeah, I didn't figure that my patch was correct.
I too am waiting to see what phk comes up with. :)
He did commit a new flag to sys/sys/conf.h on Sep. 19
"Introduce experimental SI_CHEAPCLONE flag set it on cloned bpfs."
but I have not seen anything in the source come up that uses it... yet.:
c
In message <[EMAIL PROTECTED]>, John Baldwin writes:
>I stared at the bpf code some last week, and determined that the
>extra make_dev() was in bpf's open() method in the non-devfs
>case. As such, I have a rather simple patch. However, I don't
>like a driver having to be aware of devfs. Does an
31 matches
Mail list logo
