Joystick has stopped working

[Stephen Hocking]

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 of PGS Tensor.

"We've heard that a million monkeys at a million keyboards could produce
 the Complete Works of Shakespeare; now, thanks to the Internet, we know
 this is not true."Robert Wilensky, University of California




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: SMP changes and breaking kld object module compatibility

[Matthew Dillon]

: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 spl*() calls,
It's several day's worth of additional work when we go through
the whole review / test / test-again process.  I've already gone
through this process for what was committed to -current and I have
already tested the patches under 4.x.  I do not have time to go 
through it yet again due to having to make additional difficult-to-test
changes.

If this is an issue I suppose core can vote on whether the SMP 
cleanup should be MFC'd to 4.x.  I've already laid out all the 
reasons why I think it's a good idea to do.  I don't have the 40 
man-hours it will take to guarentee compatibility with existing kld's
(even if most are probably already compatible) so if you make that
a requirement, the result will be no MFC at all.

So you guys (core) choose -- do you want 4.x to reap the benefits of
further SMP development or not?  If you choose no, beware that without
this base cleanup there is *NO* chance whatsoever of any further SMP
work being MFC'd to 4.x.  None.  Zilch.   It will have diverged too
much.  

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: SMP changes and breaking kld object module compatibility

[Matthew Dillon]

:
: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 release we've
:> ever had, and I am confident that the 4.x series of releases will be
:> the best in FreeBSD's history probably until 5.1 or 5.2.
:
:It's all in the name. I don't disagree with your assesment of the code bases.
:However, I consider your SMP changes VERY destablizing; they BREAK
:lots of modules :-(

Huh?  No they don't.  They simply require recompiling the modules.  If
they actually broke the modules I wouldn't be trying to MFC it to 
-stable.

:...
:I'm sure that we will get over it and have something that settles into a 
:quite solid product.
:
:...
:(Richard Wackerbarth <[EMAIL PROTECTED]>)

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: To MFC or not to MFC, that is the question.

[Matthew Dillon]

:
:>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 submit my own
:opinion on whether or not this is "immediate MFC" material.

The linux patch is the only patch under discussion here in regards
to the simultanious commit/MFC issue.  The SMP work was committed
to current almost a month ago so MFC'ing it now is not really an issue.
(besides, if you remember our conversation back then both of us 
actually did all of our testing of the SMP patch under 4.x rather
then 5.x).

The linux scripting patch is available, as I already posted, at:

http://www.backplane.com/FreeBSD4/

While it has not been committed to -current or -stable yet, it has
been up for review for a while (3 weeks) and I have tested extensively
while installing oracle and java under linux emulation.  And it only 
effects linux emulation so it isn't as though MFC'ing it will suddenly
break FreeBSD even under the worst possible assumptions.  As DG said,
the linux scripting patch is simply not this big a deal... I don't know
what Poul is barking at.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: __func__ not declared for kernel build (5.0-CURRENT)

[Matthew Dillon]

:
: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?
:
:> I wish these stupid standards committees would just choose
:> something that people are already using rather then make up new names!
:
:The problem is that __func__ and __FUNCTION__ are not the same thing.
:And thus it makes sense for them not the use same name.
:
:/assar

__FUNCTION__ represents the name of the C procedure you are currently
in, same as __func__ as far as I can tell.

You can define macros that use __FUNCTION__ in header files and then
use them in the C code.  This works just fine, as of around 6 years
ago (before then __FUNCTION__ in gnu C did not properly resolve when
used in a macro in a header file).

I use __FUNCTION__ all the time to implement ASSERT() macros.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: SMP changes and breaking kld object module compatibility

[Brandon D. Valentine]

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 -CURRENT.' It's used in the CVS
logs to denote when a change was migrated from the CURRENT to the STABLE
branches. 

A quick search for MFC right from the freebsd.org main page would have
returned this information.

Brandon D. Valentine
-- 
[EMAIL PROTECTED] Illegitimi non carborundum.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: SMP changes and breaking kld object module compatibility

[Will Andrews]

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-- PS+ PE++ Y+ PGP+>+++ t++ 5 X++ R+ tv+ b++> DI+++ D+ 
G++>+++ e-> h! r-->+++ y?


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: SMP changes and breaking kld object module compatibility

[Alok K. Dhir]

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 <[EMAIL PROTECTED]>
> To: Richard Wackerbarth <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: Re: SMP changes and breaking kld object module compatibility
> 
> 
> :
> :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 PROTECTED]
> :>
> :> This is a legitimate topic for discussion.
> :>
> :> 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.
> :> We should be allowed to break kernel module loader compatibility
> :> in between a .0 and a .1 release if it is deemed necessary, but that
> :> it should be avoided (as much as possible) after the .1 release.
> :
> :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 release we've
> ever had, and I am confident that the 4.x series of releases will be
> the best in FreeBSD's history probably until 5.1 or 5.2.
> 
> 5.x is going to be seriously torn up.  Maybe not as bad as people thought,
> but still seriously torn up.  It's already being torn up.  I don't think
> there is any chance of making 4.x a short-lived branch nor do I think
> we want to.  We should bask in the light of finallly having a good stable,
> high performance set of 4.x releases.
> 
> What we have is a war between the customer's need for stability,
> other customer's need for speed, and the realities that developers 
> face in not wanting to have to rewrite patches in order to MFC them,
> and wanting to have the opportunity to MFC improvements and bug fixes
> in the first place.  The SMP patch falls somewhere in the middle, and 
> I am aiming it towards the MFC side to make #3 easier.
> 
>   -Matt
>   Matthew Dillon 
>   <[EMAIL PROTECTED]>
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: __func__ not declared for kernel build (5.0-CURRENT)

[Marty Leisner]

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 
with
 > > properly.
 > 
 > You mean outside a function?  What's the proper way of dealing with 
that?
 > 
 > > I wish these stupid standards committees would just choose
 > > something that people are already using rather then make up new 
names!
 > 
 > The problem is that __func__ and __FUNCTION__ are not the same thing.
 > And thus it makes sense for them not the use same name.
 > 

What's different about them?

__func__ was defined in aztec C nearly two decades ago...I really looked
the appearance of a __func__ pseudomacro -- it made lots of stuff much easier
to understand (as opposed to __FILE__/__LINE__) -- but __func__ had to
be handled by the translater, not the preprocessor...


 > /assar
 > 
 > 
 > To Unsubscribe: send mail to [EMAIL PROTECTED]
 > with "unsubscribe freebsd-current" in the body of the message




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

csh/nls problem causing make release failure

[John W. DeBoskey]

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 
directory
*** Error code 71


   In looking at /usr/src/bin/csh/nls/finnish/Makefile, the
install rule appears to have a problem:

install:
${INSTALL} ${COPY} -o ${BINOWN} -g ${BINGRP} -m ${NOBINMODE} \
tcsh.cat ${DESTDIR}/..${NLSDIR}/${DL}/tcsh.cat


   At the beginning of a make release, the following is
executed (I believe this is the failing component):

cd ${.CURDIR}/.. && ${MAKE} installworld DESTDIR=${CHROOTDIR} NOMAN=1

   where CHROOTDIR is /snap/release in my case thus making DESTDIR the
same (/snap/release), and /syv/release in Poul-Henning's.


   I don't know enough about the nls issues to correctly fix this
problem, however, it is apparent that the install rule above
is wrong since "/snap/usr/share/..." does not exist and probably
shouldn't during a "make release".

   Could the appropriate folks please take a look at this? I'll be
more than happy to test any patchs.

Thanks,
John


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

PCM and Midi.

[Bob Martin]

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" in the body of the message

Re: buildworld breakage (netstat/route.c rev 1.43)

[Will Andrews]

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++ Y+ PGP+>+++ t++ 5 X++ R+ tv+ b++> DI+++ D+ 
G++>+++ e-> h! r-->+++ y?


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: __func__ not declared for kernel build (5.0-CURRENT)

[Assar Westerlund]

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?

> I wish these stupid standards committees would just choose
> something that people are already using rather then make up new names!

The problem is that __func__ and __FUNCTION__ are not the same thing.
And thus it makes sense for them not the use same name.

/assar


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday

[Jonathan M. Bresler]

> 
> 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 handy to havejust like with ifconfing autoloading ethernet
drivers.  i did an immediate MFC.  i was WRONG.  i should not have
done that.  even though it does strike me as an obivious win to have
the autoload.

lets let every change sit in -current for a little while
before the MFC occurs.

jmb


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: MAKEDEV warning

[Brian Somers]

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 PROTECTED]> wrote:
> >> > After building a new kernel yesterday after a cvsup the following
> >> > appeared.
> >> > 
> >> > Apr 17 23:07:42 telecast /kernel: WARNING: run /dev/MAKEDEV before
> >> > 2000-06-01 to get rid of block devices
> >> > I did a MAKEDEV all and the message still persists.
> >> > 
> >> 
> >> I get this message too whenever I mount a mfs filesystem.
> >> The line in /etc/fstab is:
> >> /dev/da0s1b /tmp  mfs rw,async,-s327680   0
> >> 
> >> The output of "ls -l /dev/*da0s1b" is:
> >> crw-r-  1 root  operator   13, 0x00020001 Dec 12 21:09 /dev/da0s1b
> >> crw-r-  1 root  operator   13, 0x00020001 Dec 12 21:09 /dev/rda0s1b
> >> 
> >> Regards
> >> Dirk
[.]
> --
> 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 explained by incompetence.
> 

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

buildworld breakage (netstat/route.c rev 1.43)

[Will Andrews]

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 -DINET6 -DIPSEC   -I/usr/obj/usr/src/i386/usr/include -c
/usr/src/usr.bin/netstat/inet6.c
cc -O -pipe -Wall -DINET6 -DIPSEC   -I/usr/obj/usr/src/i386/usr/include -c
/usr/src/usr.bin/netstat/main.c
cc -O -pipe -Wall -DINET6 -DIPSEC   -I/usr/obj/usr/src/i386/usr/include -c
/usr/src/usr.bin/netstat/mbuf.c
cc -O -pipe -Wall -DINET6 -DIPSEC   -I/usr/obj/usr/src/i386/usr/include -c
/usr/src/usr.bin/netstat/mroute.c
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/route.c:284: structure has no member named `rn_b'
/usr/src/usr.bin/netstat/route.c:308: structure has no member named `rn_r'
/usr/src/usr.bin/netstat/route.c:309: structure has no member named `rn_l'
/usr/src/usr.bin/netstat/route.c: In function `p_rtnode':
/usr/src/usr.bin/netstat/route.c:321: structure has no member named `rn_b'
/usr/src/usr.bin/netstat/route.c:329: structure has no member named `rn_b'
/usr/src/usr.bin/netstat/route.c:330: structure has no member named `rn_l'
/usr/src/usr.bin/netstat/route.c:330: structure has no member named `rn_r'
/usr/src/usr.bin/netstat/route.c:336: structure has no member named `rm_b'
[1]  + exit 1 make buildworld 2>& 1 | 
done   tee > build.log
*** Error code 1

Stop in /usr/src/usr.bin/netstat.
*** Error code 1

If Mark or Garrett could fix this ASAP that would be nice. :)

-- 
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++ Y+ PGP+>+++ t++ 5 X++ R+ tv+ b++> DI+++ D+ 
G++>+++ e-> h! r-->+++ y?


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday

[Mike Muir]

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 cvsuping with tag=RELENG_3 seems to
> give me FreeBSD 4.0-STABLE (#0: Sat Apr 22 20:59:03 PDT 2000)..

Ok wait im a moron.. been using the stable-supfile instead of the
4.x-stable-supfile.. hm.

mike.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday

[Mike Muir]

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 me FreeBSD 4.0-STABLE (#0: Sat Apr 22 20:59:03 PDT 2000)..

But besides that, this whole back and forth dont-do-this-do-that charade
is going to get pretty juvenile soon.. I mean we're (matt) already at
bad memory insults heh so how bout you both kiss/reevaluate and make up
before it gets so bad you try to keep away from each other next time
you're both at one of these conventions or whatever.. hmm now theres an
uncomfortable situation to be in for both sides.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Stale modules (Re: panic in the morning)

[Kris Kennaway]

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 PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Stale modules (Re: panic in the morning)

[Kris Kennaway]

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_?

Making them both together. Making world _does_ build modules as I said
above, you'll just run into problems if you, say, make your kernel after
cvsupping 3 days later.

Kris


In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe <[EMAIL PROTECTED]>



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: To MFC or not to MFC, that is the question.

[Mike Muir]

"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 then give me a day or so to check it out, I'll submit my own
> opinion on whether or not this is "immediate MFC" material.
> 
> That covers the operational side of the discussion, and on the
> procedural side I unfortunately see a lot of arguing about "our
> policy" for things like this in spite of the fact that there has never
> really been an absolutely clear-cut mandate about when/where things
> should be MFC'd.  It's a more complex mesh of judgement calls
> revolving around:
> 
>  o Whether the change is absolutely mandated by security criteria
>or just-plain-brokenness in -stble.
> 
>  o Whether the change is cosmetic or otherwise minor enough that
>there's no reason not to Just Do It right away.
> 
>  o How close we are to an impending release in the -stable branch
>in question.  As has been stated frequently in the past, the
>release engineer would prefer for big changes in -stable to come
>along early in the game for maximum testing time rather than
>the day before code freeze starts.
> 
> Determining where one sits with respect to all three of these
> merge-justification criteria comes down to a judgement call in each
> case, not some precise committer's checklist. I also personally don't
> mind that too much since no checklist can be written to cover all
> cases or codify the full range of "good judgement", so it ultimately
> comes down to personal opinion.  I see two very big differences of
> personal opinion on this one and am willing to arbitrate between the
> two.
> 
> In the longer-term, this kind of thing should be handled by the
> architecture group or the conflict-resolution committee depending on
> whether it's an architectural dispute or a simple clash between
> personalities or styles.  In this case, I'd say it was a job for the
> CRC if we currently had one. :)



I'll be your CRC and say stop yer bickering and discuss this like adults
(assuming you both are infact classed as such) which means no cheap shot
insults (im sure you both have great memories and excusing that would be
your workloads which im sure are right up there) and getting over
whatever personal differences either party might have.
ok good!


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: To MFC or not to MFC, that is the question.

[Mike Muir]

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

Re: SMP changes and breaking kld object module compatibility

[Jordan K. Hubbard]

> 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 disagree.

I want it treated as a full -stable branch, not some weaker derivative,
and I don't think we'll win [m]any friends in the new-4.0 convert camp
if we try to shake things up there, even with it in .0 status and the
BSDi situation.

The reasoning is quite simple:  4.0 turned out to have, in certain production
environments, far less stability problems than 3.4 and that is partially
Matt's fault for fixing things like NFS. :-)

That in turn led to a lot more early-adoption of 4.0 than expected,
and now 4.0 is being treated (and is behaving) like a full-blown
-stable release with lots of good reasons to switch to it.  The whole
dot-zero conservativeness thing was our traditional attempt to put a
happy face on situations that sucked (a .0 release being frail and
buggy) rather than having that be an actual goal.  Now that we've
finally managed to shake off the .0 curse in many respects, I'm firmly
behind the concept of treating it like any other release.

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


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: SMP changes and breaking kld object module compatibility

[Richard Wackerbarth]

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 release we've
> ever had, and I am confident that the 4.x series of releases will be
> the best in FreeBSD's history probably until 5.1 or 5.2.

It's all in the name. I don't disagree with your assesment of the code bases.
However, I consider your SMP changes VERY destablizing; they BREAK
lots of modules :-(
I'm sure that we will get over it and have something that settles into a 
quite solid product.

However, we COULD branch FreeBSD5 off of the FreeBSD4 branch rather than
the head and call the head branch something else which would get released as 
FreeBSD6 or FreeBSD 2000 or ...


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

To MFC or not to MFC, that is the question.

[Jordan K. Hubbard]

>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 submit my own
opinion on whether or not this is "immediate MFC" material.

That covers the operational side of the discussion, and on the
procedural side I unfortunately see a lot of arguing about "our
policy" for things like this in spite of the fact that there has never
really been an absolutely clear-cut mandate about when/where things
should be MFC'd.  It's a more complex mesh of judgement calls
revolving around:

 o Whether the change is absolutely mandated by security criteria
   or just-plain-brokenness in -stble.

 o Whether the change is cosmetic or otherwise minor enough that
   there's no reason not to Just Do It right away.

 o How close we are to an impending release in the -stable branch
   in question.  As has been stated frequently in the past, the
   release engineer would prefer for big changes in -stable to come
   along early in the game for maximum testing time rather than
   the day before code freeze starts.

Determining where one sits with respect to all three of these
merge-justification criteria comes down to a judgement call in each
case, not some precise committer's checklist. I also personally don't
mind that too much since no checklist can be written to cover all
cases or codify the full range of "good judgement", so it ultimately
comes down to personal opinion.  I see two very big differences of
personal opinion on this one and am willing to arbitrate between the
two.

In the longer-term, this kind of thing should be handled by the
architecture group or the conflict-resolution committee depending on
whether it's an architectural dispute or a simple clash between
personalities or styles.  In this case, I'd say it was a job for the
CRC if we currently had one. :)

- Jordan


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: SMP changes and breaking kld object module compatibility

[Matthew Dillon]

:
:>:> 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 patchset, in fact, requires that all kernel modules be 
:>:> recompiled due to the locks that were removed from the spl*() macros.
:
:   I wonder if they really must be recompiled. It sounds like that would
:improve performance, but is seems like gratuitous locking in this area
:wouldn't necessarily cause things to break.
:
:-DG
:
:David Greenman
:Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org

The cpl, cml, and interrupt lock variables and initialization of such
is gone, Kapoof.  And the semantics have changed for a few things as well.

I haven't actually tested it to see if old modules still load and
operate properly because doing the testing properly would take more time
then I have to spend.  If a KLD doesn't use spl*() calls at all it may
be ok.  I think we should resign ourselves to recompiling the KLD's,
though.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: SMP changes and breaking kld object module compatibility

[Matthew Dillon]

:
: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 PROTECTED]
:>
:> This is a legitimate topic for discussion.
:>
:> 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.
:> We should be allowed to break kernel module loader compatibility
:> in between a .0 and a .1 release if it is deemed necessary, but that
:> it should be avoided (as much as possible) after the .1 release.
:
: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 release we've
ever had, and I am confident that the 4.x series of releases will be
the best in FreeBSD's history probably until 5.1 or 5.2.

5.x is going to be seriously torn up.  Maybe not as bad as people thought,
but still seriously torn up.  It's already being torn up.  I don't think
there is any chance of making 4.x a short-lived branch nor do I think
we want to.  We should bask in the light of finallly having a good stable,
high performance set of 4.x releases.

What we have is a war between the customer's need for stability,
other customer's need for speed, and the realities that developers 
face in not wanting to have to rewrite patches in order to MFC them,
and wanting to have the opportunity to MFC improvements and bug fixes
in the first place.  The SMP patch falls somewhere in the middle, and 
I am aiming it towards the MFC side to make #3 easier.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: SMP changes and breaking kld object module compatibility

[David Greenman]

>:> 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 patchset, in fact, requires that all kernel modules be 
>:> recompiled due to the locks that were removed from the spl*() macros.

   I wonder if they really must be recompiled. It sounds like that would
improve performance, but is seems like gratuitous locking in this area
wouldn't necessarily cause things to break.

-DG

David Greenman
Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org
Creator of high-performance Internet servers - http://www.terasolutions.com
Pave the road of life with opportunities.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday

[Matthew Dillon]

:
:>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 ask for a
:>second opinion from someone who is not quite so jaded in regards to my
:>commits... say Jordan or DG.
:
:   I'm sure you're right that the impact is minor. I'm a little uncomfortable
:with immediate MFC's, even though I've been guilty of doing that myself at
:times in the past. Can we perhaps compromise and allow for a one day delay?
:At least that would catch glaring mistakes like mis-applied patches that
:happen sometimes even with highly skilled developers who have only the best
:intentions.
:
:-DG
:
:David Greenman

Sure, no problem.  I'll tell you what, I'll commit the linux scripting
patch to 5.x on wednesday as originally planned, but since the SMP MFC
is being moved to friday (at the very least) I will not MFC the scripting
patch to 4.x until friday.  ( That is, what I really want to do is to do
the SMP MFC and the scripting MFC at the same time so people only have
to recompile their kernel modules once.  It happens to work out
well ).

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday

[Mike Smith]

> 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.  It could have gone in for 4.0, but we 
wouldn't have had time to test it.  I would avoid rolling anything 
half-assed at this point in time.

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.

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: SMP changes and breaking kld object module compatibility

[Richard Wackerbarth]

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 PROTECTED]
>
> This is a legitimate topic for discussion.
>
> 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.
> We should be allowed to break kernel module loader compatibility
> in between a .0 and a .1 release if it is deemed necessary, but that
> it should be avoided (as much as possible) after the .1 release.

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.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday

[David Greenman]

>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 ask for a
>second opinion from someone who is not quite so jaded in regards to my
>commits... say Jordan or DG.

   I'm sure you're right that the impact is minor. I'm a little uncomfortable
with immediate MFC's, even though I've been guilty of doing that myself at
times in the past. Can we perhaps compromise and allow for a one day delay?
At least that would catch glaring mistakes like mis-applied patches that
happen sometimes even with highly skilled developers who have only the best
intentions.

-DG

David Greenman
Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org
Creator of high-performance Internet servers - http://www.terasolutions.com
Pave the road of life with opportunities.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

SMP changes and breaking kld object module compatibility

[Matthew Dillon]

:
:> 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 patchset, in fact, requires that all kernel modules be 
:> recompiled due to the locks that were removed from the spl*() macros.
:
: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 PROTECTED]

This is a legitimate topic for discussion.

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.  
We should be allowed to break kernel module loader compatibility
in between a .0 and a .1 release if it is deemed necessary, but that
it should be avoided (as much as possible) after the .1 release.

I would put forth that the SMP patches are a special case in that they
provide a base for which further BGL unwinding can occur in both 4.x
and 5.x without further API breakages (beyond this one).  If we do not
MFC the SMP cleanup, then there is no chance of being able to MFC 
*ANY* further SMP-related lock removal or performance work 
from 5.x to 4.x.  

I believe that it is fairly important to try to extend the SMP work
into 4.x as much as possible, otherwise certain significant performance
improvements that might be made in a very unstable 5.x will not be
available to the general public in the stable 4.x for another year.  I
expect most production machines will be running 4.x for at least the
year and a half.  To be blunt, if we don't do this now then we are
going to be behind the competition (linux, solaris) for much too long.

As an example of how important this can be I would point back to the
3.x and 4.x trees during the VM work I did.  By not MFCing from the
outset we reached a point where bug fixes going into 4.x could *not*
be backported to 3.x without a lot of work.  We reached a point 
where bug fixes (garbage after file EOF in mmaps for example) simply 
could not be backported, or required a lot of work (some of the NFS fixes
had to be rewritten for 3.x).

I think it may be even more important for 4.x and 5.x in regards to 
the SMP work.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday

[Richard Wackerbarth]

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 probably be reverted back to standard.

Well, unless I missed some REQUIREMENT in "the rules", there is nothing
to prevent you from applying to your own actions the policy that you
think should be the rule and apply to everyone.

Just because you COULD do something and stay within the letter of the law,
that is no excuse to do it.

Although I suspect that your change is a general improvement, it is certainly 
a change that might have adverse impact on some users. Therefore, I think that
if should receive closer and more widespread review before being committed to 
any of the "stable" branches.

Personally, I will use the attitude that you have been expressing to justify
my claim that FreeBSD is still just a "developers' sandbox". Until ALL the 
developers start to think about changes from the perspective of the end user,
it will remain so.

IMHO, there is entirely too much rush to force untested changes on everyone.

Every change should flow through the slowly widening set of exposures afforded
by gradual commits to the various forums.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday

[Nate Williams]

> >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 tree and shall be treated as such.

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.


Nate


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

attachable driver modules (Re: Stale modules (Re: panic in the morning))

[attila!]

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 kernel config file line to
> compile certain drivers as modules instead of statically linking them
> into the kernel.
> 

An item which would probably go a long way towards demystifying
the kernel process would be to use loader.rc to add device
modules at load time; for instance, all the Ethernet cards, the
list of which is always in flux. Theoretically, it should be
possible to go as far as the disk, tape, CD, etc. drives (no
point in floppies), and even a choice between the console and a
VT220 on a port.

Initial load would bring in a /GENERIC from which a GUI with
check the boxes would configure loader.rc and subsequent reboots
would be with the standard /kernel.

To modify an existing /kernel, reboot with /GENERIC... or make
the editor accessible, maybe even including an X option.

The Linux crowd, or at least Caldera and Corel, are trying to
beautify the install...  I have ranted for over 20 years,
starting with Bell Labs, BSD 4.0, and numerous keynotes in
Europe in the 80s (too inflammatory to the 100+ U.S. feel-good
*ix vendors). I can remember being impressed with SUN's GUI
install in the 1982 SUN 2 (I still have both a "macho" SUN 1 and
a SUN 2).

We, who as a whole live by RTFM (and my extension of
RTFS-source), have not been willing to grant the unwashed an
audience. 

But, keep in mind, Bill Gate$, with a snappy check the box
setup, marginalized us --and still does despite an "almost
usable" product with daily or hourly BSODs vs. my last
uptime of 272 days! 

It's all well and good that us 'cognizenti' or 'intelligentsia'
are perfectly happy with a command line interface. 

But X permits me to run at least 4 'xterm' windows, pine,
Xemacs, dclock, xcdplayer, xshisen, and Netscape --and have as
many as 40 open Netscape windows (great for picking e-News
articles in a batch or diversions --no backstepping). I could
care less about KDE's or Gnome's flash (in fact, KDE's visible
primary folders plus the icons are a nuisance) --hence I use the
old standby: 'TWM' which works fine for me.

the bottom line is if we (and Linux and the rest of the crowd)
wish to push Gate$' $lop off the desktop, we need to be user-
friendly --that, and hope Judge Jackson forces 'Office' into
Open Source which would sure light BadBillyG's fire!

attila out...

--
Caveat: 

No Microsoft programs or processes were used in the creation
or distribution of this message. If you are using a Microsoft
program to view this message, please be advised I am not
responsible for any harm you may suffer as a result.

___ ___ ___
  _ __ ___ | _ ) __|   \ 
freeBSD: The Power to Serve! _ __ ___  | _ \__ \ |) |
Release 5.0-CURRENT - The Fast Lane! __  _ |___/___/___/ 
It's like a wigwam -- no Gates, no Windows, and an Apache inside.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday

[Matthew Dillon]

:
: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 about for 4.x/5.x.
:
:4.x-stable is a -stable tree and shall be treated as such.

   Really, then you have a short memory.  Why don't we ask Jordan for a 
   clarification.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday

[Matthew Dillon]

:
:
: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 the current rules
developers can commit to 4.x FIRST!  And unless you can come up with 
something better then this superior attitude bullshit, that is what 
is going to happen in this particular case.

Frankly, what it comes down to is that if DG or Jordan ask me to delay,
I know they will have a damn good reason for doing so and I will of
course delay.  But you, Poul, have used up all your brownie points and
I'm getting tired of you changing the rules to suit your current whims,
and then changing them again to justify your own commits.  Your
duel-standard is getting rather tired and your words simply do not have
any weight with me any more.

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 probably be reverted back to standard.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>

:[EMAIL PROTECTED] | TCP/IP since RFC 956
:FreeBSD coreteam member | BSD since 4.3-tahoe
:Never attribute to malice what can adequately be explained by incompetence.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday

[Poul-Henning Kamp]

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 about for 4.x/5.x.

4.x-stable is a -stable tree and shall be treated as such.

--
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 explained by incompetence.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday

[Matthew Dillon]

:> :
:> :--
:> :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 shows that most of them are trivial bug fixes.  
:
:And look at how many of them had to be patched, re-merged, etc.  IMHO
:people are getting way way to loose with MFC right after a commit.  I
:don't even want to see a MFC for a 1 character spelling fixed MFC'ed
:in less than 3 days anymore.
:
:-- 
:Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]

Perfectly acceptable to me ... *IF* core decides to change the rules
they've made for the current development trees (stable and current)
and makes an official statement that covers everyone rather then just
Matt.

I think the work required to accomplish the BSDI merger is overrated 
anyway (in regards to the source tree).  I kinda expected the BSDI
people to start working on it immediately but obviously the pace is
going to be a lot slower.  

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. 

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday

[Rodney W. Grimes]

> 
> :
> :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 rather not force people to do that twice. 
> :
> :Matt, this is not a valid reason either.
> :
> :Unless there is *urgent* and *overriding* reasons, and that basically
> :means that the security-officer says so, all changes must be shaken
> :out in -current first.
> :
> :That's just the way it is Matt.  Get used to it.
> :
> :--
> :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 shows that most of them are trivial bug fixes.  

And look at how many of them had to be patched, re-merged, etc.  IMHO
people are getting way way to loose with MFC right after a commit.  I
don't even want to see a MFC for a 1 character spelling fixed MFC'ed
in less than 3 days anymore.



-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday

[Poul-Henning Kamp]

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 explained by incompetence.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday

[Rodney W. Grimes]

> 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 patchset, in fact, requires that all kernel modules be 
> recompiled due to the locks that were removed from the spl*() macros.

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 :-(.

Either way, nothing ever should me an immediate MFC, even a blantant
security hole should not be MFC'ed immediately, code needs to be
tested, and some other person might find a few niglets that need
cleaned up before you MFC it.  Who knows, you might even break the
system, and an immediate MFC would break both at once.

Never, ever should anything be immediatly merged.  IMHO, no even
spelling fixes, as I have seen those done wrong, patched, and MFC'ed
again.

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday

[Matthew Dillon]

:
: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 rather not force people to do that twice. 
:
:Matt, this is not a valid reason either.
:
:Unless there is *urgent* and *overriding* reasons, and that basically
:means that the security-officer says so, all changes must be shaken
:out in -current first.
:
:That's just the way it is Matt.  Get used to it.
:
:--
: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 shows that most of them are trivial bug fixes.  

   I will also point out that the current STABLE and CURRENT trees are
   being treated as a special case.  Jordan himself said so!  And that
   he has made a specific statement indicating that people could
   develop in the 4.x tree due to the potential breakage in the 5.x
   tree.

   This seems entirely appropriate to me.  If the rules have changed since
   that announcement, then I recommend that core make an official statement
   to correct it.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday

[Poul-Henning Kamp]

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 fixes 
>certainly do not need a waiting period.

Matt,

This does not apply to your patch.  The "simple and obvious" loophole
applies to spelling fixes and similar, not to anything which changes
behaviour of the system.

Your current patch does not qualify for immediate MFC status unless
the security officer says so.

--
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 explained by incompetence.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday

[Matthew Dillon]

: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 this particular baby.  
:
:Sorry, Matt, that is not the way it works.  Unless there is an overriding
:issue, things do not get MFC'ed immediately.
:
:You have only cited reasons why it would be much more convenient for you
:personally to MFC right away, that is not enough to justify an immediate
:MFC.
:
:--
:Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20

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 fixes 
certainly do not need a waiting period.

My reasoning has nothing to do with what is or is not personally 
convenient for me, and frankly your insinuation that it is is rather
insulting.  After all, look how long I've waited for the SMP
patches before considering MFCing those?  It sure would have been 
more convenient for me to MFC them a week after 5.0 stabilized and
before I began work on other patch sets but I didn't.  Due to the gravity
of the changes I thought it would be best to give them a really good
test run under 5.x (and note:  I received permission from 
Jordan to MFC the SMP stuff weeks ago, and even with that permission 
I decided to wait).

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 ask for a
second opinion from someone who is not quite so jaded in regards to my
commits... say Jordan or DG.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday

[Poul-Henning Kamp]

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 rather not force people to do that twice. 

Matt, this is not a valid reason either.

Unless there is *urgent* and *overriding* reasons, and that basically
means that the security-officer says so, all changes must be shaken
out in -current first.

That's just the way it is Matt.  Get used to it.

--
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 explained by incompetence.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday

[Matthew Dillon]

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 patchset, in fact, requires that all kernel modules be 
recompiled due to the locks that were removed from the spl*() macros.
This is something I would contemplate doing for 4.0->4.1, but not 
something I would consider for 4.1 onward.  Even though 4.0 is the
most stable .0 release we've ever had, it's still a .0.

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?

-Matt



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday

[Poul-Henning Kamp]

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 this particular baby.  

Sorry, Matt, that is not the way it works.  Unless there is an overriding
issue, things do not get MFC'ed immediately.

You have only cited reasons why it would be much more convenient for you
personally to MFC right away, that is not enough to justify an 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 explained by incompetence.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday

[Matthew Dillon]

:
: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.  Please
:allow the normal waiting period to elapse before you MFC.
:
:--
:Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20

It's such a simple patch, and it fixes problems that would otherwise
exist under 4.x's linux emulation, and it only effects the linux 
emulation.  And I've been running it for a while under 5.x already (as 
I said).  And I put it up for a review 2 weeks ago.  And it makes no
major infrastructure changes to the core system.

Unless you can justify a reason for it NOT to be MFC'd immediately, I
see no reason to wait for this particular baby.  That is, unless you
*like* linux applications that use scripts to start running FreeBSD
utilities even when you have all the appropriate linux packages
installed!

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday

[Poul-Henning Kamp]

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.  Please
allow the normal waiting period to elapse before you 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 explained by incompetence.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Linux emulation scripting fix to be committed to 5.x and 4.x wednesday

[Matthew Dillon]

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
installer stuff).

http://www.backplane.com/FreeBSD4/linux-script-01.diff

This patch fixes #! paths in scripts run under linux emulation, causing
/compat/linux to be searched for the script binary when the script
is exec'd from a program running under emulation.

Often linux applications run scripts to do various things.  Without
this patch these scripts effectively 'break out' of the linux emulation
(for example, use the FreeBSD version of /bin/sh instead of the linux
version of /bin/sh) which can cause compatibility problems, especially
when the scripts run other utilities that they expect to be the linux
version rather then FreeBSD version (install, cat, grep, etc...)

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.

-Matt




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: pthread_cond_broadcast() not delivered

[Daniel Eischen]

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 output gives me the impression that the broadcast did not get
> delivered anymore.
> 
> I run this program only occasionally, but with 4-current (last year) it
> worked, and I haven't changed anything mutex-/cond-related in it since
> then.
> 
> I've attached a short test-prog (1.7k) which shows the same behavior,
> compile it with "cc -D_THREAD_SAFE -pthread test.c" and run "./a.out".

If you want it to work correctly, you have to make the second thread
release the mutex.  Look at it more closely:

void *
second_thread(void *arg)
{
  /* syncronize */
  fprintf(stderr, "Second: lock.\n");
  pthread_mutex_lock(main_mutex);

  fprintf(stderr, "Second: broadcast.\n");
  pthread_cond_broadcast(main_cond);

  fprintf(stderr, "Second: unlock.\n");
  pthread_mutex_lock(main_mutex);
  ^^

  fprintf(stderr, "Second: sleep.\n");
  sleep(10);

  fprintf(stderr, "Second: exit.\n");
  pthread_exit(0);
}

-- 
Dan Eischen


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

on the road to stomping out __func__

[attila!]

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, if as indicated in ChangeLog:9854

Tue Dec  1 20:49:49 1998  Ulrich Drepper  <[EMAIL PROTECTED]>
  Stephen L Moshier  <[EMAIL PROTECTED]>
  Richard Henderson  <[EMAIL PROTECTED]>

* c-common.c (declare_function_name): Declare predefined variable
`__func__'.

makes me question why the gcc compiler which I believe was
in use for 4.0-CURRENT prior to 21 Jul 99, does not include
the declaration, particularly since the compiler used for
the compile was based on a CURRENT cvsup of 29 Jun 99

However, that still leaves me between a rock and a hard
spot! 

Kernel usage appears limited solely to two error statements
in /usr/src/sys/i386/i386/cksum.c

in_cksum.c:

238 if (len)
239 printf("%s: out of data by %d\n", __func__, len);

426 if (len)
427 printf("%s: out of data by %d\n", __func__, len);

Which is easily enough circumvented (kludged):
   
238 if (len)
243 printf("%s: out of data by %d\n", "in_cksum", len);

431 if (len)
435 printf("%s: out of data by %d\n", "in_cksum_skip", len);

Which is an abomination... and like Bruce, I question the
need for __func__ at this point...

But, beggars can not be choosers, and, it does compile,
without errors, both GENERIC and the target 'hun'.

And, even better, it appears to execute X from 4.0-CURRENT
along with Xemacs, pine, xshisen (great during long
compiles) etc. --what more could I ask for?  Easy, a good
'make world' and update of /etc files. since my cvsup is
from 000422.1619 UCT, maybe JKH's 'BOTD' in netstat.c had
not crept in...

On Sun, 23 Apr 2000, Bruce Evans <[EMAIL PROTECTED]> wrote:

+ 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 becomes Normal, if ever.
+ Using it breaks portability.  It apparently even breaks compiling
+ current kernels with the version of gcc in FreeBSD-3.4.  I think
+ __func__ was added in egcs (the Changelog entry for adding it in gcc
+ is dated Dec 1 1998).
+ 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: __func__ not declared for kernel build (5.0-CURRENT)

[Matthew Dillon]

: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 becomes Normal, if ever.
:Using it breaks portability.  It apparently even breaks compiling
:current kernels with the version of gcc in FreeBSD-3.4.  I think
:__func__ was added in egcs (the Changelog entry for adding it in gcc
:is dated Dec 1 1998).
:
:Bruce

You mean __FUNCTION__ ?

__FILE__ and __LINE__ have been standard for a long time.  The
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.  I wish these stupid standards committees would just choose
something that people are already using rather then make up new names!

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

worldbuild breakage of the day (BOTD?)

[Jordan K. Hubbard]

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/route.c:284: structure has no member named `rn_b'
/usr/src/usr.bin/netstat/route.c:308: structure has no member named `rn_r'
/usr/src/usr.bin/netstat/route.c:309: structure has no member named `rn_l'
/usr/src/usr.bin/netstat/route.c: In function `p_rtnode':
/usr/src/usr.bin/netstat/route.c:321: structure has no member named `rn_b'
/usr/src/usr.bin/netstat/route.c:329: structure has no member named `rn_b'
/usr/src/usr.bin/netstat/route.c:330: structure has no member named `rn_l'
/usr/src/usr.bin/netstat/route.c:330: structure has no member named `rn_r'
/usr/src/usr.bin/netstat/route.c:336: structure has no member named `rm_b'
*** Error code 1


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

pthread_cond_broadcast() not delivered

[Alexander Leidinger]

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 broadcast did not get
delivered anymore.

I run this program only occasionally, but with 4-current (last year) it
worked, and I haven't changed anything mutex-/cond-related in it since
then.

I've attached a short test-prog (1.7k) which shows the same behavior,
compile it with "cc -D_THREAD_SAFE -pthread test.c" and run "./a.out".
It should print something like:
---snip---
First: thread started, waiting for pthread_cond_broadcast().
Second: lock.
Second: broadcast.
Second: unlock.
Second: sleep.
First: got broadcast.
First: join.
Second: exit.
---snip---

but it prints:
---snip---
First: thread started, waiting for pthread_cond_broadcast().
Second: lock.
Second: broadcast.
Second: unlock.
Second: sleep.
Second: exit.
---snip---

and waits forever (in state "poll").

Bye,
Alexander.

-- 
Secret hacker rule #11: hackers read manuals.

http://www.Leidinger.net  Alexander+Home @ Leidinger.net
  GPG fingerprint = 7423 F3E6 3A7E B334 A9CC  B10A 1F5F 130A A638 6E7E


#include 
#include 
#include 
#include 

pthread_mutex_t *main_mutex;
pthread_cond_t  *main_cond;

void *
second_thread(void *arg);

int
main(void)
{
  pthread_t *thread;
  int thread_error, ret;

  setvbuf(stdout, NULL, _IONBF, BUFSIZ);
  setvbuf(stderr, NULL, _IONBF, BUFSIZ);

  /* mutex */
  main_mutex = (pthread_mutex_t *)malloc(sizeof(pthread_mutex_t));
  if(main_mutex == NULL)
  {
return -1;
  }

  do {
ret = pthread_mutex_init(main_mutex, NULL);
  } while(ret == EAGAIN);
  if(ret != 0) return -1;

  /* cond */
  main_cond = (pthread_cond_t *)malloc(sizeof(pthread_cond_t));
  if(main_cond == NULL)
  {
return -1;
  }

  do {
  ret = pthread_cond_init(main_cond, NULL);
  } while(ret == EAGAIN);
  if(ret != 0) return -1;

  /* lock mutex */
  pthread_mutex_lock(main_mutex);

  /* thread */
  thread = (pthread_t *)malloc(sizeof(pthread_t));
  if(thread == NULL) pthread_exit(0); /* error, not enough memory */
  /* create pthread */
  do{
thread_error = pthread_create(thread, NULL, &second_thread, NULL);
  } while(thread_error == EAGAIN);


  fprintf(stderr, "First: thread started, waiting for pthread_cond_broadcast().\n");

  /* syncronize */
  pthread_cond_wait(main_cond, main_mutex);

  fprintf(stderr, "First: got broadcast.\n");
  sleep(2);

  fprintf(stderr, "First: join.\n");
  pthread_join(*thread, NULL);

  exit(0);
}

void *
second_thread(void *arg)
{
  /* syncronize */
  fprintf(stderr, "Second: lock.\n");
  pthread_mutex_lock(main_mutex);

  fprintf(stderr, "Second: broadcast.\n");
  pthread_cond_broadcast(main_cond);

  fprintf(stderr, "Second: unlock.\n");
  pthread_mutex_lock(main_mutex);

  fprintf(stderr, "Second: sleep.\n");
  sleep(10);

  fprintf(stderr, "Second: exit.\n");
  pthread_exit(0);
}

Re: __func__ not declared for kernel build (5.0-CURRENT)

[Bruce Evans]

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 becomes Normal, if ever.
Using it breaks portability.  It apparently even breaks compiling
current kernels with the version of gcc in FreeBSD-3.4.  I think
__func__ was added in egcs (the Changelog entry for adding it in gcc
is dated Dec 1 1998).

Bruce



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Remote serial gdb is broken in -CURRENT.

[Doug Rabson]

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 noticed this too but I have no idea why. I also had to move back to
9600.

-- 
Doug Rabson Mail:  [EMAIL PROTECTED]
Nonlinear Systems Ltd.  Phone: +44 181 442 9037




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Stale modules (Re: panic in the morning)

[Donn Miller]

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 builds kernel modules.  If you followed this thread
before, I stated that modules should be built with the kernel.  After
all, they ARE kernel modules, and are part of the kernel, and not the
world.

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 kernel config file line to
compile certain drivers as modules instead of statically linking them
into the kernel.

Which mailing list would be appropriate for discussing kernel modules,
etc.?

- Donn


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Last changes to SDL made smpeg not work

[Chris Piazza]

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 seen some 
> problems with sdl test apps that mix sound & video when we use native threads 
> rather than the linux threads port.

I had just noticed this, too.  It works fine if you pass --noaudio, though.

-Chris


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Stale modules (Re: panic in the morning)

[Leif Neland]

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 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_?

Leif





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Last changes to SDL made smpeg not work

[Stephen Hocking]

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 native threads 
rather than the linux threads port.


Stephen
-- 
  The views expressed above are not those of PGS Tensor.

"We've heard that a million monkeys at a million keyboards could produce
 the Complete Works of Shakespeare; now, thanks to the Internet, we know
 this is not true."Robert Wilensky, University of California




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message