Re: dmassage - openbsd 5.4 build failure
Hi, Theo de Raadt wrote: Review the lines that dmassage has commented-out. You can fairly safely remove unused drivers for network/scsi/audio controllers/USB devices, but other drivers/pseudo-devices are more likely to give problems. Trimming out devices (especially some scsi and nic drivers) will trim out a lot, and if you then find you need to go further, you'll just need to take it step by step with educated guesses. dmassage is about 12 years old, it is useful in some cases but the generated config cannot be used directly. And remember that if you use it, you are running a non-GENERIC kernel. It isn't that we don't like people running non-GENERIC kernels. The isue is that people who run custom kernels are often the type who don't switch back to GENERIC kernels before telling us of a problem they have encountered, and they have waste our time enough in the past. So it isn't that we hate non-GENERIC kernels, it is that we hate people who treat us so poorly. I know, with both NetBSD and OpenBSD I always keep the original reference kernel installed, to boot when a problem is suspected. On machines where it is not a problem, I just keep the GENERIC and am happy with that. Sometimes a non-generic kernel is needed for certain hardware to work, but this luckily is becoming less and less the case. In this case, we were speaking about tweaking on some stranger hardware and squeezing where resources are more limited. I think dmassage being unmaintained for 12 years, and this issue just coming up now, probably says a lot about that type of person. It's a type of person who can't fix dmassage, and then, sends us a mail. Sorry, but it's the truth. If it is not broken don't fix it: fine, but it still can be made user-friendly, e.g. by marking certain commented out devices as to review or by not commenting them out at all if they are known or something like that. Or perhaps a comment line in the kernel config like do not disable this ever or if you use X, something which config fails to catch, that's all. One would think that config should catch dependencies. I wasn't saying there is a bug or something is seriously broken, just improvable. It means dmassage produces an output which is not readily usable, but needs to be massaged. Perhabs it could be noted in the manpage, instead of the cryptic POD ERRORS section. Anyway, thanks, I did not want to stir up the pot. I'll keep building kernels on a faster machine and disable options piece after piece. I just finished setting up a more modern laptop yesterday with OpenBSD! Riccardo
Re: dmassage - openbsd 5.4 build failure
On Fri, Jan 03, 2014 at 19:28, Riccardo Mottola wrote: If it is not broken don't fix it: fine, but it still can be made user-friendly, e.g. by marking certain commented out devices as to review or by not commenting them out at all if they are known or something like that. Or perhaps a comment line in the kernel config like do not disable this ever or if you use X, something which config fails to catch, that's all. One would think that config should catch dependencies. This is an area where patches may be welcome, but bug reports aren't. If you can't fix it and send a diff, we're not much interested in tracking down the problem ourselves.
Re: dmassage - openbsd 5.4 build failure
On Fri, Jan 03, 2014 at 19:28, Riccardo Mottola wrote: If it is not broken don't fix it: fine, but it still can be made user-friendly, e.g. by marking certain commented out devices as to review or by not commenting them out at all if they are known or something like that. Or perhaps a comment line in the kernel config like do not disable this ever or if you use X, something which config fails to catch, that's all. One would think that config should catch dependencies. This is an area where patches may be welcome, but bug reports aren't. If you can't fix it and send a diff, we're not much interested in tracking down the problem ourselves. Indeed.. Riccardo, you are not understanding something. dmassage is not openbsd software. It comes from someone else, I am not even going to check where. If anyone is going to fix it, it isn't misc@openbsd.org
Re: dmassage - openbsd 5.4 build failure
Riccardo, How much memory does the Omni 800 have right now? Evan Root, CCNA On Wed, Jan 1, 2014 at 6:46 PM, Theo de Raadt dera...@cvs.openbsd.orgwrote: On Wed, Jan 1, 2014, at 06:17 PM, Theo de Raadt wrote: I think dmassage being unmaintained for 12 years, and this issue just coming up now, probably says a lot about that type of person. It's a type of person who can't fix dmassage, and then, sends us a mail. Sorry, but it's the truth. Very little, if anything, has changed in either the kernel configuration procedure or the format of a kernel's dmesg in the last 12 years. So this is more a case of if it ain't broke, don't fix it. So glad to have the expert speak.
Re: dmassage - openbsd 5.4 build failure
On 2013-12-25, Riccardo Mottola riccardo.mott...@libero.it wrote: Hi, prompted by the quest of a smaller kernel on my old OmniBook 800 (for which memory modules are harder to find than a standard laptop), I tried my luck with dmassage against a stock GENERIC 5.4 kernel conf. I used the generated config fil, except that I enabled a couple of more PCMCIA drivers, which are of course all disabled except the currently inserted card. Review the lines that dmassage has commented-out. You can fairly safely remove unused drivers for network/scsi/audio controllers/USB devices, but other drivers/pseudo-devices are more likely to give problems. Trimming out devices (especially some scsi and nic drivers) will trim out a lot, and if you then find you need to go further, you'll just need to take it step by step with educated guesses. dmassage is about 12 years old, it is useful in some cases but the generated config cannot be used directly.
Re: dmassage - openbsd 5.4 build failure
On 2013-12-25, Riccardo Mottola riccardo.mott...@libero.it wrote: Hi, prompted by the quest of a smaller kernel on my old OmniBook 800 (for which memory modules are harder to find than a standard laptop), I tried my luck with dmassage against a stock GENERIC 5.4 kernel conf. I used the generated config fil, except that I enabled a couple of more PCMCIA drivers, which are of course all disabled except the currently inserted card. Review the lines that dmassage has commented-out. You can fairly safely remove unused drivers for network/scsi/audio controllers/USB devices, but other drivers/pseudo-devices are more likely to give problems. Trimming out devices (especially some scsi and nic drivers) will trim out a lot, and if you then find you need to go further, you'll just need to take it step by step with educated guesses. dmassage is about 12 years old, it is useful in some cases but the generated config cannot be used directly. And remember that if you use it, you are running a non-GENERIC kernel. It isn't that we don't like people running non-GENERIC kernels. The isue is that people who run custom kernels are often the type who don't switch back to GENERIC kernels before telling us of a problem they have encountered, and they have waste our time enough in the past. So it isn't that we hate non-GENERIC kernels, it is that we hate people who treat us so poorly. I think dmassage being unmaintained for 12 years, and this issue just coming up now, probably says a lot about that type of person. It's a type of person who can't fix dmassage, and then, sends us a mail. Sorry, but it's the truth.
Re: dmassage - openbsd 5.4 build failure
On Wed, Jan 1, 2014, at 06:17 PM, Theo de Raadt wrote: I think dmassage being unmaintained for 12 years, and this issue just coming up now, probably says a lot about that type of person. It's a type of person who can't fix dmassage, and then, sends us a mail. Sorry, but it's the truth. Very little, if anything, has changed in either the kernel configuration procedure or the format of a kernel's dmesg in the last 12 years. So this is more a case of if it ain't broke, don't fix it. If anything has changed, it's what device drivers you can rip out and still get the kernel to compile. I will admit most of the reasons for doing so today are a lot less compelling in years past, when every byte of RAM counted for something (best example being a couple of non-PCI 486 systems when you could cut the kernel size almost in half by not putting in all those useless PCI drivers). Today, you have to try to find something with less than 128MiB of RAM in it, and the odds are in your favor of having more even if it's a dumpster rescue. The only use I can think of might be security (it's much harder to use an external USB storage device if the kernel is compiled not to look for them) but I'm sure there are better ways to do even this. -- Shawn K. Quinn skqu...@rushpost.com
Re: dmassage - openbsd 5.4 build failure
On Wed, Jan 1, 2014, at 06:17 PM, Theo de Raadt wrote: I think dmassage being unmaintained for 12 years, and this issue just coming up now, probably says a lot about that type of person. It's a type of person who can't fix dmassage, and then, sends us a mail. Sorry, but it's the truth. Very little, if anything, has changed in either the kernel configuration procedure or the format of a kernel's dmesg in the last 12 years. So this is more a case of if it ain't broke, don't fix it. So glad to have the expert speak.
Re: dmassage - openbsd 5.4 build failure
Hi, Brett Mahar wrote: On Sat, 28 Dec 2013 23:42:24 +0100 Riccardo Mottola riccardo.mott...@libero.it wrote: From http://www.openbsd.org/faq/faq5.html#Why : You will not get any support from developers That's absolutely useful information :) One always politely asks for help though, What I see here is either a dependency problem inside the kernel tree or more simply a bug in dmassage, which should skip certain options perhaps. Absolute OpenBSD 2nd edition has some information. In general, try removing options one-by-one, rather than starting with a broken version and trying to get it working again. Since my goal is removing about half of the options about unused drivers, this will keep me busy until 5.5 gets out :) Riccardo
Re: dmassage - openbsd 5.4 build failure
Hi, nobody has a clue? The only definition I could find is in mpbiosvar.h and for sure mpbios.c uses it (malloc), this is why I enabled mpbios. what else could it be? I also tried removing my previous build directory, without success. Riccardo Riccardo Mottola wrote: Shawn K. Quinn wrote: On Wed, Dec 25, 2013, at 08:25 AM, Riccardo Mottola wrote: Hi, prompted by the quest of a smaller kernel on my old OmniBook 800 (for which memory modules are harder to find than a standard laptop), I tried my luck with dmassage against a stock GENERIC 5.4 kernel conf. I used the generated config fil, except that I enabled a couple of more PCMCIA drivers, which are of course all disabled except the currently inserted card. What I found is as of a few versions ago, I forget exactly when, dmassage by itself will generate a busted kernel config now. Basically, to have a working kernel you need to compile in certain drivers, even if they not show up in the dmesg. Unfortunately I've forgotten which ones they were and I don't have a system I can experiment on... For example: mpbios0 at bios0 I tried, but it is not enough... Riccardo
Re: dmassage - openbsd 5.4 build failure
On Sat, 28 Dec 2013 23:42:24 +0100 Riccardo Mottola riccardo.mott...@libero.it wrote: | Hi, | | nobody has a clue? The only definition I could find is in mpbiosvar.h | and for sure mpbios.c uses it (malloc), this is why I enabled mpbios. | | what else could it be? I also tried removing my previous build | directory, without success. | | Riccardo | | Riccardo Mottola wrote: | Shawn K. Quinn wrote: | On Wed, Dec 25, 2013, at 08:25 AM, Riccardo Mottola wrote: | Hi, | | prompted by the quest of a smaller kernel on my old OmniBook 800 (for | which memory modules are harder to find than a standard laptop), I | tried | my luck with dmassage against a stock GENERIC 5.4 kernel conf. | From http://www.openbsd.org/faq/faq5.html#Why : You will not get any support from developers Absolute OpenBSD 2nd edition has some information. In general, try removing options one-by-one, rather than starting with a broken version and trying to get it working again. Brett.
dmassage - openbsd 5.4 build failure
Hi, prompted by the quest of a smaller kernel on my old OmniBook 800 (for which memory modules are harder to find than a standard laptop), I tried my luck with dmassage against a stock GENERIC 5.4 kernel conf. I used the generated config fil, except that I enabled a couple of more PCMCIA drivers, which are of course all disabled except the currently inserted card. Build fails with: cc -Werror -Wall -Wstrict-prototypes -Wmissing-prototypes -Wno-main -Wno-uninitialized -Wno-format -Wstack-larger-than-2047 -fno-builtin-printf -fno-builtin-snprintf -fno-builtin-vsnprintf -fno-builtin-log -fno-builtin-log2 -fno-builtin-malloc -O2 -pipe -nostdinc -I../../../.. -I. -I../../../../arch -DDDB -DDIAGNOSTIC -DKTRACE -DACCOUNTING -DKMEMSTATS -DPTRACE -DCRYPTO -DSYSVMSG -DSYSVSEM -DSYSVSHM -DUVM_SWAP_ENCRYPT -DCOMPAT_43 -DCOMPAT_O51 -DCOMPAT_O53 -DLKM -DFFS -DFFS2 -DFFS_SOFTUPDATES -DUFS_DIRHASH -DQUOTA -DEXT2FS -DMFS -DNFSCLIENT -DNFSSERVER -DCD9660 -DUDF -DMSDOSFS -DFIFO -DSOCKET_SPLICE -DTCP_SACK -DTCP_ECN -DTCP_SIGNATURE -DINET -DALTQ -DINET6 -DIPSEC -DPPP_BSDCOMP -DPPP_DEFLATE -DPIPEX -DMROUTING -DMPLS -DBOOT_CONFIG -DUSER_PCICONF -DKVM86 -DUSER_LDT -DAPERTURE -DCOMPAT_LINUX -DPROCFS -DNTFS -DHIBERNATE -DPCIVERBOSE -DEISAVERBOSE -DUSBVERBOSE -DWSDISPLAY_COMPAT_USL -DWSDISPLAY_COMPAT_RAWKBD -DWSDISPLAY_DEFAULTSCREENS=6 -DWSDISPLAY_COMPAT_PCVT -DX86EMU -DONEWIREVERBOSE -DMAXUSERS=80 -D_KERNEL -MD -MP -c ../../../../arch/i386/pci/pci_machdep.c ../../../../arch/i386/pci/pci_machdep.c: In function 'pci_intr_map_msi': ../../../../arch/i386/pci/pci_machdep.c:604: error: 'mp_busses' undeclared (first use in this function) ../../../../arch/i386/pci/pci_machdep.c:604: error: (Each undeclared identifier is reported only once ../../../../arch/i386/pci/pci_machdep.c:604: error: for each function it appears in.) *** Error 1 in /usr/src/sys/arch/i386/compile/ob800 (Makefile:566 'pci_machdep.o') I suppose something got disabled which was a required dependency of something else? What could it be? Question two: option APERTURE# in-kernel aperture driver for XFree86 I suppose I can disable this, since this machine is pci only and has no AGP, right? Riccardo
Re: dmassage - openbsd 5.4 build failure
On Wed, Dec 25, 2013, at 08:25 AM, Riccardo Mottola wrote: Hi, prompted by the quest of a smaller kernel on my old OmniBook 800 (for which memory modules are harder to find than a standard laptop), I tried my luck with dmassage against a stock GENERIC 5.4 kernel conf. I used the generated config fil, except that I enabled a couple of more PCMCIA drivers, which are of course all disabled except the currently inserted card. What I found is as of a few versions ago, I forget exactly when, dmassage by itself will generate a busted kernel config now. Basically, to have a working kernel you need to compile in certain drivers, even if they not show up in the dmesg. Unfortunately I've forgotten which ones they were and I don't have a system I can experiment on... -- Shawn K. Quinn skqu...@rushpost.com
Re: dmassage - openbsd 5.4 build failure
Shawn K. Quinn wrote: On Wed, Dec 25, 2013, at 08:25 AM, Riccardo Mottola wrote: Hi, prompted by the quest of a smaller kernel on my old OmniBook 800 (for which memory modules are harder to find than a standard laptop), I tried my luck with dmassage against a stock GENERIC 5.4 kernel conf. I used the generated config fil, except that I enabled a couple of more PCMCIA drivers, which are of course all disabled except the currently inserted card. What I found is as of a few versions ago, I forget exactly when, dmassage by itself will generate a busted kernel config now. Basically, to have a working kernel you need to compile in certain drivers, even if they not show up in the dmesg. Unfortunately I've forgotten which ones they were and I don't have a system I can experiment on... For example: mpbios0 at bios0 I tried, but it is not enough... Riccardo
