Re: /sys hierarchy
On Sun, 02 Jul 2000, Warner Losh wrote:
In message [EMAIL PROTECTED] "David O'Brien" writes:
: On Sun, Jul 02, 2000 at 01:31:28PM -0600, Warner Losh wrote:
: : cd blah is currently
: : cd ../../compile/${KERNNAME}
: : it becomes
: : cd /usr/obj/`pwd`/${KERNNAME}
:
: My take on this is that it would make it slightly harder to develop
: kernel stuff in the tree. I don't like that prospect, and I think
:
: I agree that it is nicer to make the created headers, Makefile, etc. into
: /sys/compile/ , BUT it would be better to put the .o's in /usr/obj/ to
: seperate the generated binary from the [generated] source.
Having the ability to do this is great (like I said for the typical
buildworld case). Having the ability to turn it off is also desirable
to aid in normal development. Even /usr/obj can be turned off for the
normal case by setting MAKEOBJDIRPREFIX to /bogus (assuming you have
no /bogus). So too should any new feature like this be.
config
shouldn't be modified to put things in /usr/obj/`pwd`${KERNNAME}, but
instead one should use the -d feature of config in the buildkernel
target to put this into /usr/obj.
Or "config" could be rewritten to act like NORMAL unix tools and leave its
output in the directory where it is executed. IMHO, the "-d" is the backwards
way to do things. I objected when it was written, but the author insisted
that "compatability" was more important than correct design.
Write a new version under a different name and create a shell "wrapped" for
those who refuse progress.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Archive pruning
On Wed, 26 Apr 2000, you wrote: Any further discussion from you on this point that doesn't include code is totally and completely without value. You haven't proven the value of your suggestion to _anyone's_ satisfaction, so no one is going to do it for you. So if you're not willing to actually do it, please let it drop. You are correct that I "haven't proven" yet. Much of this is because the audience doesn't relate to the problem because they don't see themselves directly impacted by it. However, they are paying for it every time they use cvsup or cvs. That's the trouble with this developer community. They see EVERYTHING as WRITING CODE and "adding on". This is not about writing code. The code already exists. I am just advocating using it in a different way. As for the actual "doing", I'm quite willing to do to actual "legwork" that results from the change. But the change is a fundamental change in the way the organization "does business". Unless the organization makes a change, there is nothing to do. I think that it is just a matter of time until the matter gets raised by yet another person as the underlying problem gets more acute. I'll sit back and wait... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Archive pruning
On Wed, 26 Apr 2000, you wrote: *Bzzzt*. Wrong. You only get the old history during the intial cvsup. And since the most recent revisions are stored at the beginning of an RCS file, you don't pay for this on cvs operations except for 'cvs log' and other operations dealing with the history. Good grief, at least get your facts straight before blathering on. I suggest that YOU get your facts straight. 1) Only the head changes are written at the top of the file. For other branches, cvs has to track down to the branch point and then back out the branch. At each step, it must apply the "patch" that represents the difference in the two versions. 2) I have seen routines that append to the end of a file. However, if I insert at the front, I must copy the entire file. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Archive pruning
On Mon, 24 Apr 2000, Garrett Wollman wrote: On Mon, 24 Apr 2000 22:09:14 -0500, Richard Wackerbarth [EMAIL PROTECTED] said: You confuse the argument for SOME complete repositories with the necessity that ALL (or at each most) repositories be so extensive. You're welcome to remove whatever history you like from your personal copy. Not if I want to keep the recent history up to date. The distribution tools don't support that. It's not worth the effort to the project as a whole to save a small amount of disk space. The CVS tree is currently 843 Mbytes, complete. Storage cost (even if you buy SCSI disks) is about $16. With cheap disks, that's about $6. However, you are ignoring the cost of repeatedly (re)processing that (non)information. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Archive pruning
On Tue, 25 Apr 2000, Nate Williams wrote: No-one needs to grab a repository, unless they're looking at history. Just use CVSup to grab the latest bits, no need to grab the entire history. I find it virtually impossible to work with anything but the most stable without the recent part of the repository because I often have to "unbreak" something that was recently committed or is otherwise unfinished in order to get a working system. This is not a major complaint that I need to do so but rather the reason that I find simply cvsup'ing inadequate. Users have the choice to take it all, since trying to build a 'pruned repository' is alot of work (due to the way CVS does it's thing), Actually, it isn't. it can be automated rather easily based on parsing the CVS tags and using RCS primitives. The hard part is to get developers like yourself to recognize that they could refer to a CD for the old parts to the history and keep only the newer part in the online distribution. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Patchkits: Was :Re: SMP changes and breaking kld object module compatibility
On Tue, 25 Apr 2000, Wilko Bulte wrote: On a similar note: I think one of serious drawbacks of FreeBSD's model for updating and bugfixing the stable branch is 'make world'. It's very inefficient and cumbersome way to do this on production machines. STABLE is stable enough for us to be able to prepare binary patches, which can be applied to a system in some (known) version. Question: are MD5 checksums the same for each and every build (assuming static sources obviously) or is there some timestamp (or something like that) in the generated binary. If there is, one could only create binary patches relative to a -release. Here your logic is wrong. When I make a binary patch, I don't HAVE to update anything that is not substantively changed. Think "make all" rather than "make world". From there, it is easy enough to generate a chain of patches just like CTM does for the sources. However, is it worth the effort? I don't know. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patchkits: Was :Re: SMP changes and breaking kld object module compatibility
On Tue, 25 Apr 2000, Wilko Bulte wrote: In other words: if people did a local buildworld once on a -release sourcetree will all the executables have the same MD5 as the ones on the -release cdrom? If you are using someone's patches, you must be patching the files that they provided. If you have created your own "imposters", you cannot expect to patch them. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Archive pruning
On Tue, 25 Apr 2000, you wrote: I told myself I wouldn't get into this debate with you again, Richard, but you're not listening. The vast majority (all? I might have missed one) of the other respondants Actually, I didn't start this. Someone else brought up the idea. P.S. Please don't tell me I'm being a "sandbox developer", because I've yet to see the hordes of non-developers crying out for this system either. I don't disagree that the majority of the readers of this list are not interested. The quiet majority that might benefit are not very likely to speak up when they are told some is impossible. After all, they are at the mercy of the very developers who oppose change because it does not directly benefit the developers. I do object to the characterization by these developers that it CANNOT be done. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patchkits
On Tue, 25 Apr 2000, Kris Kennaway wrote: On Tue, 25 Apr 2000, Wilko Bulte wrote: OK. But you do have to uniquely identify the binary that needs to be patched. So, my question is when you generate 10x the same binary, will all these 10 binaries have the same MD5 checksum? In other words: if people did a local buildworld once on a -release sourcetree will all the executables have the same MD5 as the ones on the -release cdrom? I don't think a binary patch is workable: all it takes is a single local buildworld and you've got an unpatchable system. Furthermore, I'd speculate that binary patches would usually be on the same order of size as the file itself. What *would* work is including the entire new file in the package. This is what solaris does. However, there are serious regression-testing and dependency problems with a scheme like this - i.e. making sure you've included *all* of the relevant changes. Sounds like a package manager from another OS. :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Archive pruning
On Tue, 25 Apr 2000, Matthew Hunt wrote: Maintaining a CVS repository is necessary only if you are working on the code, I disagree. Anyone who attempts to run "-current" on a regular basis needs the recent history to cobble together a working system. It is also very helpful if you are a "tester" and are willing to do more than provide "Buildworld is broken today" feedback. There's always cvsweb for occasional browsing. If you are reasonably well connected. If all of the committers chip in $0.15 apiece to buy you a big enough disk, will you stop wasting our time about this? I already spent a few $100 to get 18GB on my laptop. That doesn't change my argument about the value. The costs are much more than just HD space. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Archive pruning
On Tue, 25 Apr 2000, Jordan K. Hubbard wrote: And if I put up, will you (the organization) use it? It's certainly too much work to prove the obvious. I don't have to convince myself of anything. The only value accrues if it gets used. Erm, haven't we been here with you before? I can even replay the script from heart: 1. Richard comes up with some total crack-smoking idea that only he and a few people hanging around the men's room at grand central station appear to like. Dig tunnels and get the trains off the streets. 5. People refuse to do any such thing and the proposal collapses. 6. Go to step 1. After you sit at the train crossing waiting for the train to pass. 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
On Mon, 24 Apr 2000, Matthew Dillon wrote: : 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. From the USER's perspective, anything that requires me to as much as reload a module/program that I have already installed "breaks" it. The fact that it is only necessary to recompile it in order to fix it only means that it is easy to fix IF I have the source code. 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
On Mon, 24 Apr 2000, Jeroen C. van Gelderen wrote: I don't think it was ever recommended that you upgrade your kernel without upgrading and rebuilding the modules (better still, world) at the same time. So this wouldn't really have an adverse effect, would it? Such a policy is totally unacceptable for "released" systems. Pre-release, I can accept it because the interfaces are still being tested and redesigned as needed. However, once a system is released, the users MUST have the ability to upgrade parts of the system without rebuilding everything. In fact, the user may be unable to rebuild parts of the system because he lacks the resources, be they hardware or source code. In particular, I, as a user, need to be able to purchase proprietary code and expect to be able to run it on a system. I further expect to be able to upgrade the kernel or shared libraries within the same release series and still use the same binary of the proprietary program. If this were not the case, we could argue that there is no need for the "linux compatability modes. Every Linux binary could just be recompiled into the FreeBSD format. 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
On Mon, 24 Apr 2000, Kenneth Wayne Culver wrote: I don't think it was ever recommended that you upgrade your kernel without upgrading and rebuilding the modules (better still, world) at the same time. So this wouldn't really have an adverse effect, would it? I believe that it depends on what changes were made since the last recompile, although it is good practice to at least recompile the modules when the kernel is recompiled. On a released system, I may not have the sources to recompile the module. It might be a proprietary module that I got with the hardware, for example. That is why STABLE INTERFACES are so IMPORTANT to USERS. "Current" is a sandbox. Lower expectations are part of that game. But released systems are stone houses, not sandcastles. 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
On Mon, 24 Apr 2000, Frank Mayhar wrote: 1. 4.0 hasn't been out long enough for there to be any significant support for it in proprietary systems. It takes more lead time than this. So make the change and release it as FreeBSD5. Save the big changes for something called FreeBSd6 or FreeBSD2000, or ... The vendors can simply say "we don't support" FreeBSD4. The confusion factor for users is real. This module works with FreeBSD4 kernels, but only those after April 26, 2000 just doesn't "sell". 2. Significant enhancements are often worth the price I'm not against "progress". It's just how it gets packaged. 3. Any proprietary module that depends so heavily upon kernel internals is, IMNSHO, broken by definition. If one is writing a proprietary module, particularly for an open-source system, one should write to the lowest common denominator and _not_ to internal interfaces that could change out from under you at any moment. As I understand it, it's not a fundamental change to the interface that "bites". A simple recompile will "fix" most modules. Every module that exchanges information with the kernel depends on its interfaces. 4. No system, released or otherwise, is a "stone house." At best it's a wooden house (to use your terminology), since defect fixes might require changes to internal interfaces. I know, I do this for a living. I did too. Only we were never so casual about changing interfaces after a release. 5. The SMP stuff is about _internal_ interfaces, not external ones. Internal vs External is administrative. Any time one organization provides one piece and another provides the other, the interface is, by definition, external. Loadable kernel modules can come for multiple sources. Therefore the interface to them is external. 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
On Mon, 24 Apr 2000, Alfred Perlstein wrote: I think as a whole we need to evaluate the use of macros, they're one of the major problems with changes like this and several people have come forward over time with strong numbers showing that the code bloat causes that comes with overuse of macros causes problems with the I cache where inlining really doesn't pay off. Most archs nowadays have pretty good support for leaf functions or have cheap calls instructions. Macros CAN generate function calls :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: asm_pci.h,v Holy cow!
On Mon, 24 Apr 2000, Julian Elischer wrote: This seems well thought out and I certainly agree that we don't need DIFFs of firmware. I wonder if we can somehow "cheat time" and get that 13MB file out of the source tree and retro-actively tag the new scheme so that we don't have to carry it around forever :-) It looks like a port, Smells like a port, and tastes like a port. It must be a . merlot ? Seriously, perhaps we should consider putting optional pieces of the kernel (eventually much of it, I hope) into a ports style structure. This structure can already take care of most of the problems like this one because it has multiple mechanisms whereas the source tree has only one. 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
On Mon, 24 Apr 2000, you wrote: On Mon, Apr 24, 2000 at 04:46:43AM -0500, Richard Wackerbarth wrote: From the USER's perspective, anything that requires me to as much as reload a module/program that I have already installed "breaks" it. The fact that it is only necessary to recompile it in order to fix it only means that it is easy to fix IF I have the source code. No-one forces you to upgrade you systems. Partial upgrades are something that are nice when they work, but understood when they don't. We don't accept bug reports (typically) when a person hasn't upgraded their world, kernel, and modules. I don't understand why we're accepting preemptive bitching. That is also partly why you are also lacking the respect and support of a wider audience. If you act like FreeBSD is just a "developer's sandbox", that's what it will be. If you want it to be something greater than that, you must consider what you are doing to third party developers and end users. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: asm_pci.h,v Holy cow!
On Mon, 24 Apr 2000, you wrote: Seriously, perhaps we should consider putting optional pieces of the kernel Firmware for a SCSI adapter is not optional. At least not on some of the Alpha machines that download out-of-date firmware from their SRMs so depend on the driver to load them with something up-to-date. Sure it is. I certainly have a fine system without any SCSI adapter. The whole move toward loadable modules is to make the kernel into a "cafeteria" rather than a "blue plate". That firmware is a required part of a particular driver is not in dispute. 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
On Mon, 24 Apr 2000, you wrote: On Mon, Apr 24, 2000 at 02:02:28PM -0500, Richard Wackerbarth wrote: That is also partly why you are also lacking the respect and support of a wider audience. If you act like FreeBSD is just a "developer's sandbox", that's what it will be. If you want it to be something greater than that, you must consider what you are doing to third party developers and end users. Developers and early adopters are the ones tracking -STABLE. Users are installing binary snapshots and releases. Some users do install snapshots and/or releases. Snap shots occur on a regular basis and are affected by this change in API. No-one in their right mind would release a module for "4.0-STABLE sometime between april and may". They release for 4.0-RELEASE or 4.1-RELEASE, this would not cause problems for those people. Ahh.. the problem occurs with user Z running snap 4.0-stable 4/30 when trying to use vendor X module for 4.0-release. Get it?? I certainly do. Your "attribute deamon" left out one level of identification. There are two problems here: 1) How often do the interfaces change? IMHO, too often. These sandboxers have no concept of third party issues. 2) How do we identify the version of the interface? Even if we ignore the number of "different interfaces", being able to readily recognize which one a customer has is important. Maybe the developers need to be sentenced to a tour on the customer service lines. It might open their eyes. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Archive pruning
On Mon, 24 Apr 2000, Chuck Robey wrote: I want to bring up a suggestion. I just want a little bit of argument on it ... and if you're violently opposed, just say so, that's fine. I want to suggest that, once a year, we go thru the cvs archive, and prune away all history more than 3 (or maybe 2, maybe 4) years old. This could be done without too much pain, I think, in a script. The purpose is to put some kind of cap on growth of the FreeBSD source archive. While folks do sometimes go hunting for hugely old materials in the tree, I normally couldn't care less (when browsing) about history that old. Do we really need 5 year old history? a) yes, we need the history. b) do we need it "online everywhere"? I think the answer is "no". However the sandbox engineers think differently. c) I've brought this up more than once. Do "they" care? ??? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Archive pruning
On Mon, 24 Apr 2000, you wrote: On Mon, Apr 24, 2000 at 08:15:45PM -0400, Chuck Robey wrote: I want to bring up a suggestion. I just want a little bit of argument on it ... and if you're violently opposed, just say so, that's fine. I'm "violently opposed". :-) While folks do sometimes go hunting for hugely old materials in the tree, I've often traced files back to the begining of FreeBSD time (and then continued in the CSRG SCCS tree). I've done this numerious times, especially the contributed sources like GCC and GNU grep. Do we really need 5 year old history? Yes. I don't disagree that we need to maintain the history. I do, however, question the policy that REQUIRES EVERYONE to maintain that much history. The CPU's use L1, L2, MM, HD cache hierarchies. The public libraries have a few months issues of a periodical in each branch library. They also have years of them in the main archives. FreeBSD developers know a better way to manage information??? :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Archive pruning
On Mon, 24 Apr 2000, you wrote: I'd like to add that it can be particularly important when legal questions arise. You confuse the argument for SOME complete repositories with the necessity that ALL (or at each most) repositories be so extensive. 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
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: SMP changes and breaking kld object module compatibility
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
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: Stale modules (Re: panic in the morning)
On Thu, 20 Apr 2000, Maxim Sobolev wrote: Then, we could add an option "make modules" and "make install_modules" so that they could be built/installed with the kernel. After all, modules ARE a part of the kernel... Looks like *really* nice idea. This would allow to solve "stale modules" problem at minimal cost. First we need to address the problem of "multiple kernels". Linux does this by having the modules associated with a particular kernel in a directory whose name is kernel dependent. After that, I personally think that we should treat the "kernel" as if it is just another module in the set. Rather than building a kernel, you ALWAYS build/rebuild/install the entire set. As long as the proper Makefiles are controlling the build, it won't be "expensive" for make to examine each module to verify that it is up-to-date. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5.0-current breaks building jpeg shared library
On Tue, 14 Mar 2000, Vallo Kallaste wrote: Strange, I always thought the -current list is for general issues related to -current branch ... We really should have a new mailing list since we have an additional branch. I'll again voice the opinion that the naming of the lists is sub-optimal. IMHO, we should have FreeBSD3, FreeBSD4, FreeBSD5, etc. rather than stable or current (which one?) The easiest way I see to make the transition is call the the head branch -DEVEL and leave -CURRENT for 4.x (for a while) The mailing lists can be supported by mail aliases until people learn to use new names. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/ports/ too big?
On Wed, 09 Feb 2000, Dan Papasian wrote:
An even more radical approach, and more controversial, would
be to remove /usr/ports entirely and use the concept of source packages.
pkg_add -r aumix would install the binary, and something along the lines of:
pkg-source_add -r aumix would download the source, patches, and whatever else
needed.
This is the direction that my thinking is headed. Let the actual developers
keep things (pretty much) as is. Repackage the distribution into a multi-level
hierarchy.
The top level would be a description of what's available.
{basically the DESCR files}
The second level would be the details.
{the rest of the stuff in /usr/ports/xxx/yyy/}
The third level would be the distribution tarballs.
{files presently fetched to /usr/ports/distfiles}
The ports maintainers would commit to the expanded tree just as they do now.
However, instead of distributing that tree, we would derive (automatically) the
level 2 tarballs and distribute them. The top level Makefile in /usr/ports/
would expand the level 2 build tree and continue down into it just as it does
now.
--
Richard Wackerbarth
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /usr/ports/ too big?
On Sat, 12 Feb 2000, David O'Brien wrote:
TAKE THIS TO [EMAIL PROTECTED] *
Agreed. This is where the depth of the discussion should take place.
This is NOT a -current issue!!
I beg to differ. Any significant change to the status-quo is a -current issue.
To adopt ANY SIGNIFICANT CHANGE without widespread public notice is just
inviting grumblings of "backroom politics". Just see what happens if the City
Council votes to close Main Street and explains " this was discussed at a Public
Hearing before the Public Works Commission"
And some of us, myself included, are advocating making FreeBSD into a small set
of ports!
I guess that doesn't affect very many people :-)
--
Richard Wackerbarth
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /usr/ports/ too big?
On Fri, 11 Feb 2000, Tim Vanderhoek wrote: Something of this general idea exists in the portcheckout port. If we were to have a stripped down skeleton of the ports, is it generally felt that the INDEX contains enough information? Or do we really need to have the DESCRiptions available for browsing before we go online to actually fetch the required files? -- Richard Wackerbarth [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/ports/ too big?
On Thu, 10 Feb 2000, Peter Jeremy wrote: Seems reasonable. Last time I checked (1st June 1999), I found 79967 - of which 35215 was CVS-related files/directories. There were also nearly 62,000 inodes. It'll get worse - PHK has changed the FS defaults from 8K/1K to 16K/4K, which will roughly triple the space. My favourite solution (because it's mine) would be to replace the existing each port skeleton directory with a single ar(5) file There are two problems in the size of the ports system. 1) The large number of inodes. Your proposal certainly addresses this. 2) The huge size of our ports collection. Unfortunately, this will only get worse^H^H^H^H^Hbetter. In addition to the files needed to build a port, there is a description which is quite useful. My variation on your theme is to have two files for each of the present ports. The first would be a Makefile that has the description imbedded in it. This would provide the hook to build the port and a browsable "library of available programs" The second would be your `ar` file of the patches, build instructions, etc. These would get unpacked only during the actual building of a particular port. For distribution, I would have the top level descriptions as one set. The archives could be obtained either individually or as sets corresponding to each of the present top level directories. Now, here is a really "silly" idea. Why don't we make a `port` collection of the FreeBSD kernel and standard userland utilities? That would lead to the next step of having the "standard distribution" become just a meta package much like 'kde' pulls in 'kdebase', 'kdeutils', 'kdegraphics', etc. -- Richard Wackerbarth [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/ports/ too big?
On Thu, 10 Feb 2000, Archie Cobbs wrote: Richard Wackerbarth writes: There are two problems in the size of the ports system. 1) The large number of inodes. I don't see the ports tree as the problem. The problem is that FreeBSD does not handle a very large directory hierarchy like that presented by the ports tree very well. We HAVE to live in the house. The question is "how do we make the best use of the hand that was dealt us?" Fundamentally, I object to being required/expected to maintain a copy of a large amount of information that does not impact my system. I don't care about the patches to X unless I decide to install it. Similarly, I think that it is a stupid design to require everyone to keep the ENTIRE history of a file (per cvs). I have CD roms which have the old versions in case I need to reference them. Why cannot the 4.0 branch simply "end" with a reference to the 3.x CD for those who want to dig deeper. Now, here is a really "silly" idea. Why don't we make a `port` collection of the FreeBSD kernel and standard userland utilities? This idea makes a lot of sense. All of FreeBSD could be packagable as ports/packages. It might even simplify the installer. And `make` can pull in the dependencies (-: Sorry, you cannot reuse the existing tools. You must write a new one :-) -- Richard Wackerbarth [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: flaw in modules system?
On Thu, 03 Feb 2000, you wrote: When we do a 'make install' on the kernel, it automatically copies /kernel to /kernel.old, and copies the new kernel in ... is there no way of extending this to the modules? The one thing I was thinking might be to have it so that if you 'load kernel.old' (ie. kernel didn't boot properly, so you have to revert), when it loads its modules, it loads module.old to go along with it... Basically, the modules are tied to the kernel, so is there any way of having them install along with the kernel ... ? Peter W. was working on this but it wasn't going to be ready in time for the 4.0 freeze. Therefore it got put "on hold" until 4.0 gets released. Expect it soon thereafter. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make installworld broken???
On Mon, 31 Jan 2000, you wrote:
On Sun, 30 Jan 2000, John Polstra wrote:
It's source-dir is called "xinstall" btw.
Why is the source called "xinstall"?
To avoid colliding with the standard make target "install". If we
had utilities named "all", "depend", and "clean" we'd have to do the
same thing for them.
Mhmmm... Isn't this something that .PHONY target is supposed to handle?
How does that help? The problem is namespace pollution.
Consider
cd /usr/src/usr.bin
make install
Does this mean
cd /usr/src/usr.bin/install
make all
or
.for d in ${SUBDIRS}
(cd /usr/src/usr.bin/${d}; make install)
.endfor
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
On Mon, 24 Jan 2000, Rodney W. Grimes wrote:
This does not need to really be a wrapper around cvs, folks should run
a tool 1 time to pick the best guess as to what server they should be
using, stick that value in thier cvsup file and be done with it. If
jdp calls for a ``this server is being overloaded please move'' folks
should rerun the selection tool and pick new servers. This latter
event happens 2 or 3 times a year, it is a waste to run this every time
you start up cvsup and can cause the grief if you change cvsup servers
in 1 hour due to the update policy of the mirrors.
I agree that you need to do it with a "run once (in a blue moon?)" script that
helps you select an appropriate host site. But for now, we can leave that to
"manually select a good site"
Here is a patch that I suggested to John the last time this came up.
Rather than patching the supfiles, I "patch" my local `make` configuration.
Just having this in the code might help steer users to a different site.
If we can get most users off of "cvsup.FreeBSD.ORG", we could change that DNS
CNAME to point the underutilized site of the week.
--- src/Makefile.inc1~ Tue Jan 25 04:12:36 2000
+++ src/Makefile.inc1 Tue Jan 25 04:21:00 2000
@@ -407,17 +407,20 @@
@echo "--"
@echo " Running ${SUP}"
@echo "--"
+.if defined(FreeBSD_SUPSITE)
+SITEFLAGS= -h ${FreeBSD_SUPSITE}
+.endif
.if defined(SUPFILE)
- @${SUP} ${SUPFLAGS} ${SUPFILE}
+ @${SUP} ${SUPFLAGS} ${SITEFLAGS} ${SUPFILE}
.endif
.if defined(SUPFILE1)
- @${SUP} ${SUPFLAGS} ${SUPFILE1}
+ @${SUP} ${SUPFLAGS} ${SITEFLAGS} ${SUPFILE1}
.endif
.if defined(SUPFILE2)
- @${SUP} ${SUPFLAGS} ${SUPFILE2}
+ @${SUP} ${SUPFLAGS} ${SITEFLAGS} ${SUPFILE2}
.endif
.if defined(PORTSSUPFILE)
- @${SUP} ${SUPFLAGS} ${PORTSSUPFILE}
+ @${SUP} ${SUPFLAGS} ${SITEFLAGS} ${PORTSSUPFILE}
.endif
.endif
.if defined(CVS_UPDATE)
--- src/etc/defaults/make.conf~ Tue Jan 25 04:14:36 2000
+++ src/etc/defaults/make.conf Tue Jan 25 04:16:42 2000
@@ -197,6 +197,7 @@
#
#SUP=/usr/local/bin/cvsup
#SUPFLAGS= -g -L 2
+#FreeBSD_SUPSITE= cvsup8.FreeBSD.ORG
#SUPFILE=/usr/share/examples/cvsup/standard-supfile
#SUPFILE1= /usr/share/examples/cvsup/secure-supfile
#PORTSSUPFILE= /usr/share/examples/cvsup/ports-supfile
Fwd: RE: /dev/smb0 on Dell Latitude
Thanks for your suggestion. I haven't found anything in the archives that seems to apply. Any help from "current"? -- Forwarded Message -- Subject: RE: /dev/smb0 on Dell Latitude Date: Wed, 13 Oct 1999 17:53:06 -0500 From: "Alejandro Ramirez" [EMAIL PROTECTED] Hi, You should write this question to [EMAIL PROTECTED], there was some discusion about this. Ales - Original Message - From: Richard Wackerbarth [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 13, 1999 5:09 PM Subject: /dev/smb0 on Dell Latitude Help! Does anyone have any experience with the smbus on Dell laptops? This is today's kernel. Selected entries in dmesg are below. When I attempt to find devices the ioctl returns "Device not configured" on /dev/smb0. FreeBSD 4.0-CURRENT #9: Wed Oct 13 08:21:53 CDT 1999 CPU: Pentium II/Xeon/Celeron (267.27-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x650 Stepping = 0 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV, PAT,PSE36,MMX,FXSR real memory = 67043328 (65472K bytes) apm0: APM BIOS on motherboard apm: found APM BIOS v1.2, connected at v1.2 pcib0: Intel 82443BX host to PCI bridge (AGP disabled) on motherboard pci0: PCI bus on pcib0 vga-pci0: NeoMagic NM2160 laptop SVGA controller irq 11 at device 2.0 on pci0 pcic0: TI PCI-1131 PCI-CardBus Bridge irq 11 at device 3.0 on pci0 pcic1: TI PCI-1131 PCI-CardBus Bridge irq 11 at device 3.1 on pci0 isab0: Intel 82371AB PCI to ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 ide_pci0: Intel PIIX4 Bus-master IDE controller at device 7.1 on pci0 chip1: UHCI USB controller irq 11 at device 7.2 on pci0 intpm0: Intel 82371AB Power management controller at device 7.3 on pci0 intpm0: I/O mapped 840 intpm0: intr IRQ 9 enabled revision 0 smbus0: System Management Bus on intsmb0 smb0: SMBus general purpose I/O on smbus0 intpm0: PM I/O mapped 800 pcm0: SoundBlaster Pro 3.2 at drq 1 flags 0x15 on isa0 device_probe_and_attach: pcm0 attach returned 6 devclass_alloc_unit: pcf0 already exists, using next available unit number pcf0 at port 0x320 irq 5 on isa0 pcic: pccard bridge VLSI 82C146 (5 mem 2 I/O windows) WARNING: driver smb should register devices with make_dev() (dev_t = "#smb/0") To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
On Thu, 30 Sep 1999, Marcel Moolenaar wrote: Sub-problem B (sigframe) doesn't need to be handled, because: 1. none of the tools require ... Correct, this is a "non-problem". Sub-problem A (syscalls) can be easily handled if the syscalls are added to a -stable kernel. Wrong. I CANNOT rebuild the kernel that runs my build machine. What we need is to (effectively) remove these syscalls from the tools in question. This can be done with conditional compilation or a compatability library. Each tool should be evaluated for its functionality. If the host's tool has the required functionality, there is no reason to upgrade it in order to build the "foreign" (4.0) system. For example, "cat". If the host's tool is inappropriate, we MUST build a cross-build version. In many cases, this simply means that we compile the source of the tool with the host's headers. In others, it is more complex, but it can, and should, be done. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
On Wed, 12 May 1999, Mike Smith wrote: This option should automatically select the appropriate sources which is compiled into kernel, according to the source is needed only in UP case, or only in SMP case, or both. This is what oldconfig and newconfig does. This is, again, defective reasoning. For a usable dynamic architecture, loadable modules need to be compiled to support both UP and SMP architectures simultaneously. Thus the locking primitives need to be conditionalised at _runtime_. Or, alternately, at load time by choosing the appropriate subsystem to match the hardware. It is clearly possible to arrange that lowest-common-denominator code is initially loaded and then replaced with a configuration optimized version. The configuration at compile time is in the Makefile to cause, when appropriate, the various versions to be compiled from common code. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: kernel.old
I wish :-( It seems that some people think that it is OK to make changes to stable even though those changes break things which used to work. IMHO, branches of the kernel SHOULD be like shared libraries. (It is OK to ADD previously absent features or CORRECT internal errors, but NOT OK to delete features or change API's) On Sun, 9 May 1999, Poul-Henning Kamp wrote: I think you are seeing -current as the norm. You shouldn't. Under -stable the modules should (tm) continue to work since there are not made API changes in -stable. Personally, I think that we should treat kernels just like another library. They export an API (sysctl) that libc, et. al. uses and another API that the kernel modules use. Any change that breaks code which is compliant with those API's belongs in a new release branch. PERIOD. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /var/db/pkg/.mkversion
I have to agree that the problem is real. However, let me point out that a one identifier solution is very short sided. There are two distinct environments to be considered. The HOST environment and the TARGET environment. For convience, we should also consider a TOOLSET environment which is a cross between the two. Just as it is wrong to use compiler variables like, __FreeBSD__ to control target compilations (except as a default), it is also wrong to do so for the ports. The group has come around to the idea that the files in /usr/include represent the HOST and not the TARGET. I suggest that you dig out my old proposal for tagging the HOST in /usr/include. The natural tag for the TARGET would be in /usr/src/include. However, I can see some problems with this for the ports tree. The more general mechanism allows us to register capabilities. (Shades of some commercial OS'es) However, we may not want to do things in such a unified manner :-) On Thu, 1 Apr 1999, Satoshi - the Wraith - Asami wrote: It has been pointed out many times in the past that we need something to ensure bsd.port.mk can synchronize itself with the rest of the system The question is, can I ask you to make sysinstall write some kind of version info that can be used by bsd.port.mk to identify the age of the system? The problem is real, we've been bitten too many times in the past (haven't you seen all the where's fetch -A? and other more subtle breakages that are caused by ports and system mismatch) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /var/db/pkg/.mkversion
On Thu, 1 Apr 1999, Chuck Robey wrote: On Thu, 1 Apr 1999, Richard Wackerbarth wrote: The natural tag for the TARGET would be in /usr/src/include. However, I can see some problems with this for the ports tree. Richard, don't forget that having /usr/src isn't required to build ports. I don't think that I did forget. I explicitly reference that situation. The real solution (re the TARGET) has to depend on something that the USER sets for a particular run. As such, it should be an environment variable which defaults to the HOST value. At the same time, the ports have to consider the purpose for which they need the identification. For example, fetch -A is a HOST/TOOLSET situation. But selecting the set of sysctls to compile into the code is a TARGET question. Nobody said cross compilation is easy :-) The simple solution for ports may be to build 3.1 packages on 3.1 machines and 4.0 packages only on 4.0 systems. In that case, TARGET == HOST and things are much easier. I still see nothing wrong with /usr/include for a place to store a tag about the HOST. Alternately, the traditional place would be /etc. The format of the tag should be considered. IMHO, it is best if we can have one knob which works for make, sh, and cc. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /var/db/pkg/.mkversion
On Thu, 1 Apr 1999, Satoshi - the Wraith - Asami wrote: * From: Richard Wackerbarth r...@dataplex.net * very short sided. sighted : Yes, a slight transfer error between my brain and 'sendmail'. * There are two distinct environments to be considered. * The HOST environment and the TARGET environment. This issue has nothing to do with hosts and targets. The ports tree has never supported building ports on a system with a version other than the one that is going to run it. (And we don't intend to start doing it any time soon either, sorry. ;) I recognize that. However, I bring it up because there are a number of programmers who still fail to recognize the distinction. I hope that we can get the rest (non-ports) of the build system into shape. Any solution for the ports should be one that also works elsewhere. As a result, I would hate to see yet another inadequate mechanism become entrenched. I don't think that ports ever stands a real chance in making it to cross compilation because too many of the components rely on autoconf style configuration. This often trys to decide which representation to use by trial and error. It is virtually impossible for you to police all those ports authors and have them maintain cross-compile compliance. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /etc/rc.conf, take 46!
On Sun, 21 Mar 1999, Jordan K. Hubbard wrote:
Index: netstart
===
RCS file: /home/ncvs/src/etc/netstart,v
retrieving revision 1.53
diff -u -u -r1.53 netstart
--- netstart 1999/02/10 18:08:16 1.53
+++ netstart 1999/03/22 01:54:16
@@ -12,8 +12,11 @@
# If there is a global system configuration file, suck it in.
if [ -f /etc/defaults/rc.conf ]; then
. /etc/defaults/rc.conf
-elif [ -f /etc/rc.conf ]; then
- . /etc/rc.conf
+ for i in ${rc_conf_files}; do
+ if [ -f $i ]; then
+ . $i
+ fi
+ done
fi
There is a problem with this approach.
/etc/defaults/rc.conf defines ${rc_conf_files}
However, I have no chance to override it before it is used.
When I wrote my comment about code in rc.conf, I was
actually thinking about /etc/defaults/rc.conf and the
recursion loop that that creates when someone copies it to
/etc/rc.conf.
You can, and IMHO should, make the defaults strictly variables.
However, I fear that you need a bit more logic to allow the
overriding of ${rc_conf_files}.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: /etc/rc.conf, take 46!
On Mon, 22 Mar 1999, John Baldwin wrote:
On 22-Mar-99 Richard Wackerbarth wrote:
There is a problem with this approach.
/etc/defaults/rc.conf defines ${rc_conf_files}
However, I have no chance to override it before it is used.
However, I fear that you need a bit more logic to allow the
overriding of ${rc_conf_files}.
Where are going to override it? If we use some other config file that gets
sucked in to /etc/defaults/rc.conf we'd have a config file included in
another config file that tells it what other config files to include. If this
keeps up we'll end up with a bunch of config files floating around that config
other config files, which will end up messy and confusing for newbies, IMHO.
Unless someone comes up with a scheme that tracks set membership and
allows us to add to that set, I think that we should stick to the simple
approach.
/etc/defaults/rc.conf defines ${rc_conf_files} to be /etc/rc.conf
/etc/rc.conf is allowed to override this definition to include additional
files such as /etc/rc.conf.local
Those files get sucked in.
- - -
An alternate, and perhaps cleaner approach would be to always suck in
/etc/defaults/rc.conf and /etc/rc.conf. Then suck in those files specified
in ${additional_rc_conf_files}.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: /etc/rc.conf, take 46!
On Mon, 22 Mar 1999, John Baldwin wrote:
An alternate, and perhaps cleaner approach would be to always suck in
/etc/defaults/rc.conf and /etc/rc.conf. Then suck in those files specified
in ${additional_rc_conf_files}.
That would work, but then we have two includes everywhere that we have 1 now.
Then wrap the logic into a single call.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: Possible fix for rc.conf
Why do we need to have ANY of the file inclusion in /etc/defaults/rc.conf?
Shouldn't that file simply be definitions of variables?
IMHO, the logic should be in rc itself.
On Sat, 20 Mar 1999, Scot W. Hetzel wrote:
What does everyone think about using this at the end of
/etc/defaults/rc.conf?
for i in ${rc_conf_files}; do
if [ $0 != $i ]; then
if [ -f $i ]; then
. $i
fi
else
echo Error: $0 isn't allowed to re-load $i.
echo Error: Please do not copy /etc/defaults/rc.conf to
/etc/rc.conf
fi
done
If someone does copy the /etc/defaults/rc.conf to /etc/rc.conf, /etc/rc.conf
will not reload it's self, thus it will never get stuck in an endless loop.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: gcc
At 01:28 PM 3/1/99 -0800, Jordan K. Hubbard wrote:
It really does appear to be a simple matter of first making egcs take over
the system compiler:
# cd /usr/ports/lang/egcs
# make all install PREFIX=/usr
# ln -fs /usr/bin/eg++ /usr/bin/c++
# ln -fs /usr/bin/egcc /usr/bin/cc
# cd /usr/src
remove cc from /usr/src/gnu/usr.bin/Makefile SUBDIR list
remove libstdc++ and libobjc from /usr/src/gnu/lib/Makefile SUBDIR list
Although this approach works, IMHO, the more appropriate approach
would be to use ${CC} rather than cc in ALL the makefiles and then
define CC=/usr/bin/egcc
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
On Wed, 10 Feb 1999, John Fieber wrote: On Wed, 10 Feb 1999, jack wrote: If /etc/rc.conf only contains changes from the defaults when man something_or_other tells the user to find and edit something_or_other_flags in /etc/rc.conf the entry won't be there to edit. Why must it contain only changes? Is there any reason it couldn't be a copy of the default rc.conf on a new installation? Alternately, it could be a copy of the default file with every item commented out. That would provide the clues for those who need to edit values and still not mess up the default behavior of a new install with old options that might have changed but were not explicitly overridden. The documentation in the file could also suggest that the user remove anything that they do not need. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Which DHCP client
Jordan, I object to the idea that the selection of which dhcp client is being made on the basis that David has commit privledges and I do not. Further, it is clear that David has not used a recent release of the isc client and is biasing his opinion with false assertions. It is my opinion that we should not use this criteria to decide which client will become a part of the base system. I have been bmakeing the isc client for almost a year. Requests to get assistance in comitting it went unanswered. I believe the isc client to be a better choice. If size is a real concern, perhaps we should treat this client as we do the shell in PicoBSD. I'm not convinced that the differences are that great. However, the flexability is :-) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
Personally, I have to side with Matt. I like to have ALL of the files in one directory. That way I can grep ntpd /etc/rc* and find ALL the line that are likely to affect it. Moving some of the files into another directory just complicates things. I like the idea of having all the default knobs in one file. I recommend /etc/rc.conf.defaults On Tue, 9 Feb 1999, Jordan K. Hubbard wrote: If you want to put 'read only' junk into /etc/defaults, then why aren't you also sticking /etc/rc, /etc/rc.network, /etc/rc.firewall, etc etc etc into /etc/defaults ? It makes no sense to have an /etc/defaults/ directory if you are still mixing read-only and user-modifiable files in /etc. There is an eventual plan to put more things into /etc/defaults, yes. One has to, however, start somewhere. :) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
I understand the scaling issue. However, I like to keep related things in one place. Perhaps we need to move ALL the rc files into a common directory. As for the read-only argument, I recommend, for those who wish to separate them, symbolic links from the read only area to a writable area. When that is not important, keeping them together can have advantages. Please understand that I support the general direction of these changes. However, since it is just about the same effort to implement any of the proposals and the status quo has a big advantage, I think that it is important to discuss the implications of each of the stratagies before commiting to any of them. PS: The same applies to DHCP. Since some of the well respected names have also supported ISC-DHCP, I hope that we can reach a concensus before anyone is allowed to make their bias the de-facto answer. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
I tend to prefer that the editable knobs be kept together. The uneditable scripts and the defaults can go together. If you are going to divide things, I don't see why you should put uneditable scripts with editable knobs and apart from uneditable knobs. On Tue, 9 Feb 1999, RT wrote: I kinda like the /etc./defaults directory... All default files should be placed there. Only things edited should be in /etc.. It'll make for a much smaller mess of files. I'm wondering about items like ppp examples? I would either turn examples into defaults OR expect them to go away when someone sets up their own version. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Heads up! /etc/rc.conf.site is dead.
But, I would not expect/allow defaults to be the mechanism which includes the real values. Perhaps this should be pushed into the script that will source both. On Wed, 10 Feb 1999, Sheldon Hearn wrote: The only difference is the addition of a no touchees reference copy in /etc/defaults that gets sourced before rc.conf so any essential variables introduced in an upgrade will have a safety fallaback in case you don't properly upgrade your rc.conf. That's it? That's what all this is about? Hell, now that you've put it like that, it sounds like a really _great_ idea. Even the choice of directory name ``defaults'' makes sense, now. :-) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: adding DHCP client to src/contrib/
On Tue, 9 Feb 1999, Daniel O'Connor wrote: On 09-Feb-99 Charlie ROOT wrote: Further, the assertion that it is easier to configure the WIDE client is WRONG. The ISC CLIENT requires NO configuration. I don't see how anything can be simpler. :-) Hmmm.. This annoyed me actually.. There is NO config file which means its damn annoying for you to tweak how it works.. Almost like a windows app really :) This also is incorrect. You MAY have a configuration file to override the defaults. In most cases, the defaults are just fine and the configuration file may be omitted. However, all the knobs are there for those who need them. The WIDE client's default config file is usually quite OK. As I said, the ISC clients (non-existant) file is equally acceptable. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Network Cards
On Thu, 4 Feb 1999, Daniel C. Sobral wrote: Rod Taylor wrote: I've often wondered this, but why is it that every network card has a different 'name'. xl0, rl0, vr0, ed0, etc. etc. etc The best solution would be hardwiring the names, but in that case it doesn't matter what are the default names. Yes. Hardwiring is the only appropriate solution. It should be done as a part of the loader kernel configuration. Perhaps it should work somewhat like the SCSI disk partitions. Unspecified interfaces get the next available slot. However, and this is the important point, it is very useful to be able to assign an identifier to the logical interface and have that identifier appear in EVERY reference to the interface. I would like to hardwire 00:aa:bb:cc:dd:ee which uses the vr driver to eth23 and have ifconfig accept and report the device as 'eth23'. The actual driver is parenthetical. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
