>
> 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
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
:
:>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.
>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
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
:
: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
24 matches
Mail list logo
