Re: Kernel "roughing in" tool
Otto Moerbeek writes: > And as explained in FAQ section 5.6, there are many more reasons not > to do it. and amplified by 5.7 "It is assumed you have read the above[Section 5.6], and really enjoy pain." before it proceeds to a description of how you would go about customizing. - P -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Kernel "roughing in" tool
On Sat, Apr 14, 2012 at 10:21:27AM +1000, David Diggles wrote: > > What a waste of time. And it is well known that we don't even look at > > problem reports that use a custom kernel. > > A sore point perhaps? This has nothing to do with that. You are told by the experts (developers) to not do something. Of course you are free ignore that advice and to do otherwise. But don't expect encouragment or support. > > Still worth noting, there is sometimes a reason to modify a kernel > or cut down its size, and that is why the procedure is documented on > openbsd.org. And as explained in FAQ section 5.6, there are many more reasons not to do it. -Otto
Re: Kernel "roughing in" tool
On 04/13/12 20:21, David Diggles wrote: What a waste of time. And it is well known that we don't even look at problem reports that use a custom kernel. A sore point perhaps? Still worth noting, there is sometimes a reason to modify a kernel or cut down its size, and that is why the procedure is documented on openbsd.org. It isn't a sore point, it's the simple fact a non-supported kernel can be a bear to work on. ...Is the problem real, or introduced by the person making the special kernel? Once off of 486's, I've never had a reason to cut down the size of a kernel. The standard bsd and bsd.mp kernels have never failed me. If you're *adding* something into the kernel, I think that would be a different story and you could get people to help you. --STeve Andre'
Re: Kernel "roughing in" tool
> What a waste of time. And it is well known that we don't even look at > problem reports that use a custom kernel. A sore point perhaps? Still worth noting, there is sometimes a reason to modify a kernel or cut down its size, and that is why the procedure is documented on openbsd.org.
Re: Kernel "roughing in" tool
> Joe Gain wrote: > So much for diversity, I guess. Chaos bringing diversity is not desirable. > I find the group-think here fairly disappointing, especially as this > is the general usage list and not just for OpenBSD developers. The purpose of this group (list) is not the personal please of Joe Gain. You've touched a very sensible subject, called kernel tweaking. It has a long history well documented in the FAQ and the mailing list. > Sounds like party-member arse-licking. Maybe for you.
Re: Kernel "roughing in" tool
Alan Corey wrote: > I've just uploaded a small program I wrote for configuring a kernel > based on the devices found by doing a dmesg with a generic kernel. You mean like Camiel Dobbelaar's "dmassage" Perl script from 2002? ;-) I still keep a copy around because it can print a pretty device tree like this: root \-mainbus0 |-bios0 | |-apm0 | \-pcibios0 |-cpu0 \-pci0 |-auich0 | \-audio0 |-ehci0 | \-usb0 | \-uhub0 |-ichiic0 | \-iic0 | \-spdmem0 |-ichpcib0 | \-isa0 | |-aps0 | |-isadma0 | |-npx0 | |-pckbc0 | | |-pckbd0 | | | \-wskbd0 | | \-pms0 | | \-wsmouse0 | \-pcppi0 |\-spkr0 |-pchb0 |-pciide0 | \-wd0 |-ppb0 | \-pci1 | |-cbb0 | | \-cardslot0 | | |-cardbus0 | | \-pcmcia0 | |-em0 | |-iwi0 | \-sdhc0 |\-sdmmc0 |-uhci0 | \-usb1 | \-uhub1 |-uhci1 | \-usb2 | \-uhub2 |-uhci2 | \-usb3 | \-uhub3 \-vga1 |-intagp0 | \-agp0 |-inteldrm0 | \-drm0 \-wsdisplay0 -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Kernel "roughing in" tool
On Fri, Apr 13, 2012 at 12:18 AM, Joe Gain wrote: > So much for diversity, I guess. I find the group-think here fairly > disappointing, especially as this is the general usage list and not just > for OpenBSD developers. Someone suggests doing A. Doing A makes answering questions and resolving problems harder. If lots of people do A, device support will be slower and more costly. No one has started a mailing list or built a community of people that are interested in supporting people that do A. What are you proposing to do? Are you going to provide that support and assist people that do A? Or are you complaining that the other people are not volunteering to spend their time on giving that support *instead of* doing general development of OpenBSD? Is supporting other people doing A more important than what other people are doing right now? Philip Guenther
Re: Kernel "roughing in" tool
So much for diversity, I guess. I find the group-think here fairly disappointing, especially as this is the general usage list and not just for OpenBSD developers. Sounds like party-member arse-licking. On Fri, Apr 13, 2012 at 8:25 AM, Martin Schrvder wrote: > 2012/4/13 Alan Corey : > > I've just uploaded a small program I wrote for configuring a kernel > based on > > the devices found by doing a dmesg with a generic kernel. It tries to > detect > > Are you happy supporting CoreyBSD? > > -- joe gain jacob-burckhardt-str. 16 78464 konstanz germany +49 (0)7531 60389 (...otherwise in ???)
Re: Kernel "roughing in" tool
2012/4/13 Alan Corey : > I've just uploaded a small program I wrote for configuring a kernel based on > the devices found by doing a dmesg with a generic kernel. It tries to detect Are you happy supporting CoreyBSD?
Re: Kernel "roughing in" tool
On Thu, Apr 12, 2012 at 11:46:29PM -0400, Alan Corey wrote: > I've just uploaded a small program I wrote for configuring a kernel > based on the devices found by doing a dmesg with a generic kernel. > It tries to detect whether you're running a generic kernel by > looking at uname output then runs dmesg via a pipe, copies over > /usr/src/sys/arch/i386/conf/GENERIC line by line, commenting out > devices it doesn't find in dmesg. It's only been tested with i386, > but was written under 5.0 and also tested under 4.7. I'm running > both kernels now. It's very generic C and hopefully has no > dependancies. > > Alan > > http://ab1jx.webs.com/calcs/kr/index.html "I do not have SCSI disks". I bet some you have some in your house like SD card readers or external USB drives. What a waste of time. And it is well known that we don't even look at problem reports that use a custom kernel. -Otto
Re: Kernel "roughing in" tool
On 04/12/12 23:46, Alan Corey wrote: I've just uploaded a small program I wrote for configuring a kernel based on the devices found by doing a dmesg with a generic kernel. It tries to detect whether you're running a generic kernel by looking at uname output then runs dmesg via a pipe, copies over /usr/src/sys/arch/i386/conf/GENERIC line by line, commenting out devices it doesn't find in dmesg. It's only been tested with i386, but was written under 5.0 and also tested under 4.7. I'm running both kernels now. It's very generic C and hopefully has no dependancies. Alan http://ab1jx.webs.com/calcs/kr/index.html Hello Alan, Neat idea in theory, but actually horrid in the real world. If we were on 486's with 32M ram as my ancient Compudyne's were, it would make sense, and in fact I made SHRIMP kernels for a while-- But then one day I was demoing OpenBSD to some people and they wanted to see it run on their shiny new P3 Dell. Not having a CD handy I moved the disk over to the Dell were it booted, but couldn't get on the net. I'd zapped out the 3com definitions on SHRIMP, to save space. I did save space but I certainly didn't save face. I danced around that as well as I could, but that and a few other incidents taught me that trying to be "efficient" had costs. When I lost a web server once I found an unused Dell and got the server up and running again in about 5 minutes. Thinking about where I'd have been with SHRIMP, I'd have lost more time, etc. Moral: efficiencies today are not what they were in 1995 and it just doesn't make sense to do that. You get points for doing this, but this particular item isn't a good thing to do. --STeve Andre' ps: you won't get any help from people here with a shredded kernel, either.
Re: Kernel "roughing in" tool
Alan Corey writes: > I've just uploaded a small program I wrote for configuring a kernel based on > the devices found by doing a dmesg with a generic kernel. It tries to detect > whether you're running a generic kernel by looking at uname output then runs > dmesg via a pipe, copies over /usr/src/sys/arch/i386/conf/GENERIC line by > line, commenting out devices it doesn't find in dmesg. It's only been tested > with i386, but was written under 5.0 and also tested under 4.7. I'm running > both kernels now. It's very generic C and hopefully has no dependancies. > > Alan > > http://ab1jx.webs.com/calcs/kr/index.html Expect hatred. Just doing text processing over the output of dmesg(8) won't give you the complete list of drivers required to run a machine properly. It may work, or it may not, and imho it's just making it easier for users to shoot themselves in the foot. For no real good reason. -- JC)rC)mie CourrC(ges-Anglas GPG fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494
Kernel "roughing in" tool
I've just uploaded a small program I wrote for configuring a kernel based on the devices found by doing a dmesg with a generic kernel. It tries to detect whether you're running a generic kernel by looking at uname output then runs dmesg via a pipe, copies over /usr/src/sys/arch/i386/conf/GENERIC line by line, commenting out devices it doesn't find in dmesg. It's only been tested with i386, but was written under 5.0 and also tested under 4.7. I'm running both kernels now. It's very generic C and hopefully has no dependancies. Alan http://ab1jx.webs.com/calcs/kr/index.html
