For sometime now, the analogue joy stick driver hasn't been working - it seems
to persistently return totally wild deviations when being read. Also, trying
to use it as a kld doersn't seem to work. Has anyone else had similar probs?
Stephen
--
The views expressed above are not those
:I'm sure that something can be done for the kld compatibility issues
:so that you can have your SMP cake and eat it too. Just give it a bit
:more thought. :)
:
:- Jordan
Thought I have. Time I don't. While I don't particularly see a
problem staying compatible with KLD modules that do
:
:On Sun, 23 Apr 2000, Matthew Dillon wrote:
:>
:> :Rather than break the FreeBSD4 modules over which you have no control,
:> :perhaps your arguments should be used to accelerate the 5.0 release
:> :and make 4.x a short lived branch.
:>
:> I don't think this is possible. 4.0 is the most sta
:
:>Really, then you have a short memory. Why don't we ask Jordan for a
:>clarification.
:
:How about if you let me review the patches in question and I'll render
:a decision.
:
:If you, Matt, could put the SMP and linux stuff into -current first
:and then give me a day or so to check i
:
:Matthew Dillon <[EMAIL PROTECTED]> writes:
:> obviously missing __FUNCTION__ was added by GCC many years ago, but it was
:> a while before it's use in defines in header (.h) files was dealt with
:> properly.
:
:You mean outside a function? What's the proper way of dealing with tha
On Mon, 24 Apr 2000, Alok K. Dhir wrote:
>
>Totally off topic question that I've wondered for some time now - what
>does MFC stand for?
According to the FAQ section located on the web @
http://www.freebsd.org/FAQ/misc.html#AEN3908
Q: What does 'MFC' mean?
A: MFC is an acronym for 'Merged From
On Mon, Apr 24, 2000 at 12:36:45AM -0400, Alok K. Dhir wrote:
> Totally off topic question that I've wondered for some time now - what
> does MFC stand for?
Merge From CURRENT.
--
Will Andrews <[EMAIL PROTECTED]>
GCS/E/S @d- s+:+>+:- a--->+++ C++ UB P+ L- E--- W+++ !N !o ?K w---
?O M+ V-- P
Totally off topic question that I've wondered for some time now - what
does MFC stand for?
Thanks for humoring my ignorance, and thanks for all your hard work on
FreeBSD...
:)
On Sun, 23 Apr 2000, Matthew Dillon wrote:
> Date: Sun, 23 Apr 2000 13:31:34 -0700 (PDT)
> From: Matthew Dillon <[EMA
Assar Westerlund <[EMAIL PROTECTED]> writes on 24 Apr 2000 02:43:28 +0200
> Matthew Dillon <[EMAIL PROTECTED]> writes:
> > obviously missing __FUNCTION__ was added by GCC many years ago,
but it was
> > a while before it's use in defines in header (.h) files was dealt
Hi,
As Poul-Henning has pointed out, make release is broken...
===> bin/csh/nls
===> bin/csh/nls/finnish
install -c -o root -g wheel -m 444 tcsh.cat
/snap/release/../usr/share/nls/fi_FI.ISO_8859-1/tcsh.cat
install: /snap/release/../usr/share/nls/fi_FI.ISO_8859-1/tcsh.cat: No such file or
d
Does anyone know when PCM will support midi?
Thanks!
Bob
--
"I know not with what weapons World War III will be fought,
but World War IV will be fought with sticks and stones."
-- Albert Einstein
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current"
On Sun, Apr 23, 2000 at 06:44:51PM -0400, Will Andrews wrote:
> If Mark or Garrett could fix this ASAP that would be nice. :)
Never mind, this was an oversight on my part.
--
Will Andrews <[EMAIL PROTECTED]>
GCS/E/S @d- s+:+>+:- a--->+++ C++ UB P+ L- E--- W+++ !N !o ?K w---
?O M+ V-- PS+ PE
Matthew Dillon <[EMAIL PROTECTED]> writes:
> obviously missing __FUNCTION__ was added by GCC many years ago, but it was
> a while before it's use in defines in header (.h) files was dealt with
> properly.
You mean outside a function? What's the proper way of dealing with that?
>
>
> BTW; whilst I think Poul was entirely the wrong person to raise the
> issue, I agree that you probably want to hang back on MFCing the linux
> scripting changes for a week or so. This is really just common sense.
>
recently i added autoload to a usb related kernel module.
very ha
Yep, that's the ticket ! Thanks.
> Yes, that was an oversight on my part. Please let me know if the
> fix I committed solves this issue.
>
> Poul-Henning
>
> In message <[EMAIL PROTECTED]>, Brian Somers writes:
> >I've got an mfs /tmp too :-]
> >
> >> Hi,
> >>
> >> On 0, Ted Sikora <[EMAIL
Buildworld on 5.0-CURRENT is breaking here:
===> usr.bin/netstat
cc -O -pipe -Wall -DINET6 -DIPSEC -I/usr/obj/usr/src/i386/usr/include -c
/usr/src/usr.bin/netstat/if.c
cc -O -pipe -Wall -DINET6 -DIPSEC -I/usr/obj/usr/src/i386/usr/include -c
/usr/src/usr.bin/netstat/inet.c
cc -O -pipe -Wall -D
Mike Muir wrote:
>
> Nate Williams wrote:
>
> > I was under the impression that 4.x hasn't been designated as the stable
> > branch (yet). That will happen when 4.1 is released, but until that
> > happens 3.x is still considered the -stable release.
>
> That would kinda make sense since cvsupi
Nate Williams wrote:
> I was under the impression that 4.x hasn't been designated as the stable
> branch (yet). That will happen when 4.1 is released, but until that
> happens 3.x is still considered the -stable release.
That would kinda make sense since cvsuping with tag=RELENG_3 seems to
give
On Sun, 23 Apr 2000, Donn Miller wrote:
> Which mailing list would be appropriate for discussing kernel modules,
> etc.?
freebsd-arch.
Kris
In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PR
On Sun, 23 Apr 2000, Leif Neland wrote:
> > make world doesn't build a kernel. Making a kernel doesn't build
> > modules. This bit me again the other day when updating, as well - panic at
> > boot when loading a stale linux.ko.
> >
> If making world _and_ kernel doesn't build modules, what _then
"Jordan K. Hubbard" wrote:
>
> >Really, then you have a short memory. Why don't we ask Jordan for a
> >clarification.
>
> How about if you let me review the patches in question and I'll render
> a decision.
>
> If you, Matt, could put the SMP and linux stuff into -current first
> and t
Good greif that last one failed to go to stable@ or current@.. time to
fix mail.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
> In general I agree with the concept but I think .0 releases have to
> have a bit more flexibility, and that 4.0 in particular (due to the
> rules change made for the BSDI merger) has to be even more flexible.
And this is something I can render an opinion on right away: I disagr
On Sun, 23 Apr 2000, Matthew Dillon wrote:
>
> :Rather than break the FreeBSD4 modules over which you have no control,
> :perhaps your arguments should be used to accelerate the 5.0 release
> :and make 4.x a short lived branch.
>
> I don't think this is possible. 4.0 is the most stable releas
>Really, then you have a short memory. Why don't we ask Jordan for a
>clarification.
How about if you let me review the patches in question and I'll render
a decision.
If you, Matt, could put the SMP and linux stuff into -current first
and then give me a day or so to check it out, I'll
:
:>:> There's another good reason to MFC the linux patch on wednesday...
:>:> that is, to do it at the same time the SMP cleanup is MFC'd, and that
:>:> is because both patch sets require the linux kernel module to be
:>:> recompiled and I'd rather not force people to do that t
:
:On Sun, 23 Apr 2000, Matthew Dillon wrote:
:
:> :In that case I have a strong objection to the SMP patchset being
:> :merged to 4.0. I have kernel modules in object format only that
:> :are working now, which this would break :-(.
:> :
:> :Rod Grimes - KD7CAX @ CN85sl - (RWG25)
>:> There's another good reason to MFC the linux patch on wednesday...
>:> that is, to do it at the same time the SMP cleanup is MFC'd, and that
>:> is because both patch sets require the linux kernel module to be
>:> recompiled and I'd rather not force people to do that twice.
:
:>I do not consider the linux scripting patch to be a major infrastructure
:>change, I consider it to be a simple bug fix. If you have a functional
:>issue with the patch I'm all ears. If you disagree with my assessment of
:>the triviality of the linux scripting patch, then I
> I wonder if it makes sense to add a release id to the module header
> and have the module loader refuse (unless forced) to load modules that
> are out-of-date with the kernel?
We actually have a whole module dependancy and versioning system more or
less ready to go into -current.
On Sun, 23 Apr 2000, Matthew Dillon wrote:
> :In that case I have a strong objection to the SMP patchset being
> :merged to 4.0. I have kernel modules in object format only that
> :are working now, which this would break :-(.
> :
> :Rod Grimes - KD7CAX @ CN85sl - (RWG25)
> : [EMAIL
>I do not consider the linux scripting patch to be a major infrastructure
>change, I consider it to be a simple bug fix. If you have a functional
>issue with the patch I'm all ears. If you disagree with my assessment of
>the triviality of the linux scripting patch, then I will as
:
:> There's another good reason to MFC the linux patch on wednesday...
:> that is, to do it at the same time the SMP cleanup is MFC'd, and that
:> is because both patch sets require the linux kernel module to be
:> recompiled and I'd rather not force people to do that twice.
:>
On Sun, 23 Apr 2000, Matthew Dillon wrote:
> If core wants to change the current rules, that's fine by me. As I
> said before I think the breakage that we thought would happen with 5.x
> due to the BSDI merger that prompted the loose rules for 4.x is
> overrated, and the rules should
> >Core should consider reverting the special rules that were originally
> >created with the expectation of major breakage in 5.x back to
> >the set of rules we had for 3.x and 4.x.
>
> I have no idea what special rules you are talking about for 4.x/5.x.
>
> 4.x-stable is a -stable
On Sun, 23 Apr 2000, Donn Miller wrote:
> I'd like to discuss further the possibility of creating some sort of
> mechanism where the modules can be built with the kernel. Also, we
> can have some sort of option in LINT or GENERIC where a keyword, such
> as module, can be put somewhere in the ke
:
:In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
:
:>Core should consider reverting the special rules that were originally
:>created with the expectation of major breakage in 5.x back to
:>the set of rules we had for 3.x and 4.x.
:
:I have no idea what special rules you are
:
:
:Matt,
:
:I will say it this last time:
:
: Your patch does not qualify for immediate MFC.
:
:--
:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
And I will say this to you for the last time: Under the current rules
my patch DOES qualify for an immediate MFC. Hell, by t
In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
>Core should consider reverting the special rules that were originally
>created with the expectation of major breakage in 5.x back to
>the set of rules we had for 3.x and 4.x.
I have no idea what special rules you are talking a
:> :
:> :--
:> :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
:>
:>I think you're confused, Poul. I've gone over the commits made
:>to the tree by people over the last few months and frankly there
:>are dozens of simultanious -current and -stable commits. A quick
:>check
>
> :
> :In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
> :
> :>There's another good reason to MFC the linux patch on wednesday...
> :>that is, to do it at the same time the SMP cleanup is MFC'd, and that
> :>is because both patch sets require the linux kernel module to be
>
Matt,
I will say it this last time:
Your patch does not qualify for immediate MFC.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be
> There's another good reason to MFC the linux patch on wednesday...
> that is, to do it at the same time the SMP cleanup is MFC'd, and that
> is because both patch sets require the linux kernel module to be
> recompiled and I'd rather not force people to do that twice.
>
>
:
:In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
:
:>There's another good reason to MFC the linux patch on wednesday...
:>that is, to do it at the same time the SMP cleanup is MFC'd, and that
:>is because both patch sets require the linux kernel module to be
:>recompile
In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
>I'm sorry, Poul, but you are going to have to come up with better
>reasoning then that.
>
>Not all changes committed to -current require a waiting period before
>being MFC'd to stable. Specifically, simple and obvious bug f
:In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
:
:>:I don't see anything justifying an immediate MFC in this patch. Please
:>:allow the normal waiting period to elapse before you MFC.
:>
:>Unless you can justify a reason for it NOT to be MFC'd immediately, I
:>see no reason to wa
In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
>There's another good reason to MFC the linux patch on wednesday...
>that is, to do it at the same time the SMP cleanup is MFC'd, and that
>is because both patch sets require the linux kernel module to be
>recompiled and I'd
There's another good reason to MFC the linux patch on wednesday...
that is, to do it at the same time the SMP cleanup is MFC'd, and that
is because both patch sets require the linux kernel module to be
recompiled and I'd rather not force people to do that twice.
The SMP pat
In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
>:I don't see anything justifying an immediate MFC in this patch. Please
>:allow the normal waiting period to elapse before you MFC.
>
>Unless you can justify a reason for it NOT to be MFC'd immediately, I
>see no reason to wait for
:
:In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
:
:>I intend to commit this to -current and immediately MFC it to -stable.
:>I don't expect there to be any controversy though I'm sure there is a
:>cleaner way to do it.
:
:I don't see anything justifying an immediate MFC in t
In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
>I intend to commit this to -current and immediately MFC it to -stable.
>I don't expect there to be any controversy though I'm sure there is a
>cleaner way to do it.
I don't see anything justifying an immediate MFC in this patch.
This is the same patch I put up for review two weeks ago. I got one
positive comment back and nothing else, so I presume nobody has a
problem with it. I've been running with it for a while but have only
tested it with a few linux applications (Java (jre, jdk), and the oracle
Alexander Leidinger wrote:
> Hi,
>
> (14) netchild@ttyp2% uname -a
> FreeBSD Magelan.Leidinger.net 5.0-CURRENT FreeBSD 5.0-CURRENT #14: Fri Apr 21
>17:28:37 CEST 2000 root@:/big/usr/src/sys/compile/WORK i386
>
> I've an application which uses pthread_cond_{wait,broadcast}() and
> the debug
you're correct (see reply from Bruce Evans below) __func__ is
in /usr/src/contrib/gcc/c-common.c
ChangeLog:9854: `__func__'.
c-common.c:164:/* Make bindings for __FUNCTION__, __PRETTY_FUNCTION__, and __func__.
*/
c-common.c:190: declare_hidden_char_array ("__func__", name);
which
:On Sat, 22 Apr 2000, attila! wrote:
:
:> '__func__ is not found for either the 'GENERIC' or 'hun' target.
:
:__func__ is a new feature in C99. It is an alias for the gcc feature
:__FUNCTION_NAME. Both give the name of the current function as a string.
:
:This feature should not be used unt
cc -O -pipe -Wall -DINET6 -DIPSEC -I/usr/obj/usr/src/i386/usr/include -c /usr/
src/usr.bin/netstat/ipx.c
cc -O -pipe -Wall -DINET6 -DIPSEC -I/usr/obj/usr/src/i386/usr/include -c /usr/
src/usr.bin/netstat/route.c
/usr/src/usr.bin/netstat/route.c: In function `p_tree':
/usr/src/usr.bin/netstat/
Hi,
(14) netchild@ttyp2% uname -a
FreeBSD Magelan.Leidinger.net 5.0-CURRENT FreeBSD 5.0-CURRENT #14: Fri Apr 21 17:28:37
CEST 2000 root@:/big/usr/src/sys/compile/WORK i386
I've an application which uses pthread_cond_{wait,broadcast}() and
the debug output gives me the impression that the b
On Sat, 22 Apr 2000, attila! wrote:
> '__func__ is not found for either the 'GENERIC' or 'hun' target.
__func__ is a new feature in C99. It is an alias for the gcc feature
__FUNCTION_NAME. Both give the name of the current function as a string.
This feature should not be used until C99 be
On Sun, 23 Apr 2000, Greg Lehey wrote:
> In the last few days, my remote serial gdb has almost completely
> stopped working. Previously I had (almost) no trouble at 38400 bps;
> now I can barely get a response at all at 9600 bps. Does anybody have
> an idea where this could be coming from?
I
Leif Neland wrote:
> > make world doesn't build a kernel. Making a kernel doesn't build
> > modules. This bit me again the other day when updating, as well - panic at
> > boot when loading a stale linux.ko.
> >
> If making world _and_ kernel doesn't build modules, what _then_?
Making world build
On Sun, Apr 23, 2000 at 03:28:54PM +0800, Stephen Hocking wrote:
> The mpeg player smpeg doesn't work (catches a signal then just hangs) when you
> compile & link against the SDL which uses the native threads - however when
> you compile against one that uses linux threads, then it does. I've se
On Wed, 19 Apr 2000, Kris Kennaway wrote:
> On Wed, 19 Apr 2000, Christoph Kukulies wrote:
>
> > I cvsup'ed, built world and kernel. Hhmm, actually I see no reason why
> > there should be a problem since everything should be done by make world.
>
> make world doesn't build a kernel. Making a
The mpeg player smpeg doesn't work (catches a signal then just hangs) when you
compile & link against the SDL which uses the native threads - however when
you compile against one that uses linux threads, then it does. I've seen some
problems with sdl test apps that mix sound & video when we use
63 matches
Mail list logo
