Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday
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
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
: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
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
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
Linux emulation scripting fix to be committed to 5.x and 4.x wednesday
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: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday
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
Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday
: :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
: :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
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
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
: :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
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
Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday
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: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday
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
: :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
: : :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
: :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
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: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday
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
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
Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday
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
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
