Re: Removal of compat-FreeBSD
Le 09/02/2015 10:12, Marc Balmer a écrit : I intend to remove the compat-FreeBSD support from the system. [...] This is what motivates my proposal. Ok? Generally it would be a good idea, but there are obviously some tw_cli users. So they need a working alternative first, imo. Maybe 3Ware would help, if being asked? It is true that, now that tw_cli works on FreeBSD, little effort is required to make it work on NetBSD. Are you ready to ask 3Ware?
Re: Removal of compat-FreeBSD
Le 13/02/2015 13:33, Marc Balmer a écrit : Am 13.02.15 um 12:34 schrieb Maxime Villard: Le 09/02/2015 10:12, Marc Balmer a écrit : I intend to remove the compat-FreeBSD support from the system. [...] This is what motivates my proposal. Ok? Generally it would be a good idea, but there are obviously some tw_cli users. So they need a working alternative first, imo. Maybe 3Ware would help, if being asked? It is true that, now that tw_cli works on FreeBSD, little effort is required to make it work on NetBSD. Are you ready to ask 3Ware? That would not make sense, I don't have the hardware. I don't either. Someone?
Re: Removal of compat-FreeBSD
Apparently, compat-FreeBSD is needed by tw_cli users. Therefore I think I will just disable it by default in the GENERIC kernels, unless anyone disagrees. Le 07/02/2015 12:19, Maxime Villard a écrit : Hi, I intend to remove the compat-FreeBSD support from the system. It has a limited interest since no major proprietary software is developed on FreeBSD; if one were, it would certainly be available on Linux, and we have full compatibility support for that. You will also notice, after reading the code a bit, that our FreeBSD layer is really poor: many syscalls are missing, the translation is not efficient, and the layer is only available on i386. Recent FreeBSD-10 binaries often crash. Recently we found two enormous bugs so obvious and harmful that we should normally have received a bug report from a user somewhere. We didn't, which means that in 6 years nobody tested compat-FreeBSD - nobody being the developers and the users. Clearly, we should not waste time and energy on something that simply does not work. compat-FreeBSD could give the impression NetBSD has a reliable way to execute FreeBSD binaries, which is far from being the case. This is what motivates my proposal. Ok?
Re: Interrupt storm mitigation needed
Joerg Sonnenberger jo...@britannica.bec.de writes: From what I see from the original message, there are two issues: (1) It's a shared interrupt. (2) uhci is generated interrupts when it should not. Also ehci. Here are the updated counters, with usage info: interrupt total ratedevice used? cpu0 timer 6817487 99 ioapic0 pin 4 4590com0yes (console) ioapic0 pin 1460piixide0no (idle cd player) ioapic0 pin 16 4271176uhci0 no ioapic0 pin 18 706564 10uhci2 yes (rs232 dongle) radeon0 no (idle frame buf) ioapic0 pin 23 1590273 23ehci0 no cmdide0 no (idle ide ctrl) ioapic1 pin 14 2920953 42amr0yes (3 ld devices) ioapic2 pin 0 6814339 99wm0 yes (vlan trunk) Total 19277198 282 uhci0, uhci2, and ehci0 are all getting lots of erroneous interrupts, while only uhci2 is actually used, and at a very, very much lower rate than what is indicated here. It is unknown to what extent amr0 and wm0 may be getting hit, but the data I have from captures of 'vmstat -i 10' output when hangs occurred indicates that they aren't. -tih -- Popularity is the hallmark of mediocrity. --Niles Crane, Frasier
Re: Interrupt storm mitigation needed
On Fri, Feb 13, 2015 at 01:19:49PM +0100, Joerg Sonnenberger wrote: On Thu, Feb 12, 2015 at 09:02:37PM -0500, Thor Lancelot Simon wrote: On Thu, Feb 12, 2015 at 07:52:10PM +0100, Tom Ivar Helbekkmo wrote: Tom Ivar Helbekkmo t...@hamartun.priv.no writes: The uhci pins on the ioapics are chalking up a few interrupts, but not many, and no bursts. Still nothing bad happening, but I did reboot just now, and saw something that I've observered a few times lately: when the machine was just sufficiently up that I could log in, 'vmstat -i' told me that the ioapic pin for uhci2 had already generated slightly more than 21 interrupts. I guess the next question would then be whether, with uhci in polled mode, we can safely mask that pin. From what I see from the original message, there are two issues: (1) It's a shared interrupt. (2) uhci is generated interrupts when it should not. We saw this on a platform of similar vintage at a former employer of mine, and indeed the uhci was one of the devices involved. Eventually we managed to produce working platform-dependent code to reroute the interrupt (Hi, Darran!). However, before that was working, I tried disabling the interrupt and polling the uhci and the other device involved (actually, in our case, we were lucky -- we were already polling the other device). That worked pretty well. But it looks like Tom's still getting the interrupt, which means, at least, that he's paying the overhead of a quick Nope, no handler for this one! return from the interrupt handling code. How far upstream is it possible to disable or mask it, I wonder, without breaking another device you care about or having to switch *it* to polled mode? Thor
Re: Removal of compat-FreeBSD
Maxime Villard m...@m00nbsd.net writes: Apparently, compat-FreeBSD is needed by tw_cli users. Therefore I think I will just disable it by default in the GENERIC kernels, unless anyone disagrees. Our norms for significant changes are more or less about consensus or preponderance of opinion. So far you've said that you want to remove/disable this, and a number of people have said they use it. No one else has spoke up in favor of disabling. We don't have evidence that anyone (besides you) is disabling this in their kernels. So I think the opinions to date fall well short of enough to support even disabling by default. pgpP0xlryfxiv.pgp Description: PGP signature
Re: Interrupt storm mitigation needed
Tom Ivar Helbekkmo t...@hamartun.priv.no writes: uhci0, uhci2, and ehci0 are all getting lots of erroneous interrupts, Also, studying my log of a ping that's sending one ICMP ECHO per second to the machine from another host on the local network, I see that whereas without Jörg's changes I had periodic hangs, I now have periods of varying lengths when the ping times jump from the normal sub-millisecond rtt to between 15 and 20 milliseconds. -tih -- Popularity is the hallmark of mediocrity. --Niles Crane, Frasier
Re: Making dhcpcd work on diskless clients
On 08/02/2015 14:10, Greg Troxel wrote: Roy Marples r...@marples.name writes: I don't fully understand what you are saying. But do you have an idea of how this can be fixed then without dhcpcd having to learn the routing table at load time? It seems to me that on a diskless client, the only really sound approach is to ensure that the DHCP client startup does not change the address and subnet route (and maybe the default route). That requires a process of checking the routes and fixing if different, vs remove/add. That might not be too hard, to be able to go an RTM_GET and look at the result. I've taken this approach and it's mostly working. dhcpcd cannot detect the first IPv6 route added (the kernel says it's not there, which is a lie - need to look at this more) but finds every other route I can throw at it. I've not testing anything else, like moving a subnet to another interface and that might be quite broken now. If anyone wants to test it so far there is a tarball here to download: http://www.netbsd.org/~roy/dhcpcd-6.7.99.1.tar.bz2 Roy
Re: Removal of compat-FreeBSD
Am 13.02.15 um 12:35 schrieb Maxime Villard: Apparently, compat-FreeBSD is needed by tw_cli users. Therefore I think I will just disable it by default in the GENERIC kernels, unless anyone disagrees. I disagree. People still use it.
Re: Dealing with debugging macros for printing as part of aprint clean-up
In article 20150208103806.ga1...@norite.fritz.box, Izaak yitz...@inbox.ru wrote: Hi, Sorry for my silence on the aprint project. I was busy in the last while, but I have more time to dedicate to it now. Anyway, I am currently working on the first task, converting printf to the appropriate aprint during autoconfiguration. Having read through many files, I have found that often printf is wrapped in a macro like 'DPRINTF', which is occasionally used both in the driver attachment function and also elsewhere in the file. I am not sure whether to replace the 'printf' inside the macro; make a new macro just for attachment; replace the macro with a direct call to an aprint function. Also, some macros contain uprintf, ttyprintf or tprintf (e.g. /sys/dev/acpi/acpi_apm.c) -- Martin told me to leave those intact. I suppose this question holds also for general macro usage, so what is the best way to deal with that? I think it is best to leave them alone too for now... christos
Re: Removal of compat-FreeBSD
jo...@britannica.bec.de (Joerg Sonnenberger) writes: ... As such I find disabling COMPAT_FREEBSD by default a very good idea for increasing the visibility of the problem. Disabling it by default makes it invisible and forces it to bitrot. And I tend to believe that that's the intention behind the suggestion. -- -- Michael van Elst Internet: mlel...@serpens.de A potential Snark may lurk in every tree.
Re: Removal of compat-FreeBSD
On Fri, Feb 13, 2015 at 07:05:00PM +0100, Maxime Villard wrote: Le 13/02/2015 15:26, Greg Troxel a écrit : Maxime Villard m...@m00nbsd.net writes: Apparently, compat-FreeBSD is needed by tw_cli users. Therefore I think I will just disable it by default in the GENERIC kernels, unless anyone disagrees. Our norms for significant changes are more or less about consensus or preponderance of opinion. So far you've said that you want to remove/disable this, and a number of people have said they use it. No one else has spoke up in favor of disabling. Perhaps because I am the only one who read the code? You said FreeBSD binaries crash. Obviously the one that is of interest for COMPAT_FREEBSD users doesn't, so in a way, who cares about the rest? Now, if there are security issues for the kernel, you'd definitely have a case. And there might very well be, but from your initial post it was more about the receiving end of COMPAT_FREEBSD. -- Quentin Garnier - c...@cubidou.net See the look on my face from staying too long in one place [...] every time the morning breaks I know I'm closer to falling KT Tunstall, Saving My Face, Drastic Fantastic, 2007. pgpqpC05O_I3G.pgp Description: PGP signature
Re: Dealing with debugging macros for printing as part of aprint clean-up
On Fri, Feb 13, 2015 at 05:17:24PM +, Christos Zoulas wrote: In article 20150208103806.ga1...@norite.fritz.box, Izaak yitz...@inbox.ru wrote: Having read through many files, I have found that often printf is wrapped in a macro like 'DPRINTF', which is occasionally used both in the driver attachment function and also elsewhere in the file. I am not sure whether to [...] suppose this question holds also for general macro usage, so what is the best way to deal with that? I think it is best to leave them alone too for now... I think that specifically for autoconfiguration it would be better to replace the debugging wrapper macro with the aprint_debug and aprint_debug_dev for attachment and then leave the macro in place for the rest of the file. I am only suggesting it because I have seen this in a few places already, so I am afraid if I leave it then the clean-up will leave behind many printf occurrences -- of course, those would be fixed in part 2 of the project anyway though. What do you think of that instead? -- Izaak
Re: Removal of compat-FreeBSD
Date: Fri, 13 Feb 2015 20:24:19 +0100 From: Joerg Sonnenberger jo...@britannica.bec.de On Fri, Feb 13, 2015 at 09:26:48AM -0500, Greg Troxel wrote: Our norms for significant changes are more or less about consensus or preponderance of opinion. So far you've said that you want to remove/disable this, and a number of people have said they use it. I have asked the same question a long time ago when we pruned a bunch of other obsolete emulations. From a security stand point, I fully agree with Maxime. Agree with gdt@ on protocol and with joerg@ and maxv@ on security. Removal from GENERIC, but not src yet, sounds good to me, especially if COMPAT_FREEBSD can be invoked from userland without privileges.
Re: Removal of compat-FreeBSD
On Fri, Feb 13, 2015 at 09:26:48AM -0500, Greg Troxel wrote: Maxime Villard m...@m00nbsd.net writes: Apparently, compat-FreeBSD is needed by tw_cli users. Therefore I think I will just disable it by default in the GENERIC kernels, unless anyone disagrees. Our norms for significant changes are more or less about consensus or preponderance of opinion. So far you've said that you want to remove/disable this, and a number of people have said they use it. No one else has spoke up in favor of disabling. We don't have evidence that anyone (besides you) is disabling this in their kernels. I have asked the same question a long time ago when we pruned a bunch of other obsolete emulations. From a security stand point, I fully agree with Maxime. The usefulness of the FreeBSD emulation is *very* limited, it can't even handle most FreeBSD 4 binaries. I find it highly questionable to keep a non-trivial attack surface for the sake of a single device driver, which most people likely don't even have. I don't see any evidence in the tree of COMPAT_FREEBSD improving or any of the users of tw_cli working on improving the situation by removing the need for it. As such I find disabling COMPAT_FREEBSD by default a very good idea for increasing the visibility of the problem. Maybe someone who should be caring actually starts to... Joerg
Re: A brelse() in FFS...
m...@m00nbsd.net (Maxime Villard) writes: Hi, this may be a stupid question; in ufs/ffs/ffs_vfsops.c, l.1153: if (fs-fs_sbsize SBLOCKSIZE) brelse(bp, BC_INVAL); else brelse(bp, 0); However 'fs-fs_sbsize' is *always* smaller than SBLOCKSIZE. So only the first branch is reached. It can also be equal to SBLOCKSIZE (or larger than SBLOCKSIZE if corrupted). I don't understand what the BC_INVAL flag means, and its definition in sys/buf.h is not very enlightening: #define BC_INVAL0x2000 /* Does not contain valid info. */ BC_INVAL means, there is no data in the buffer that could be reused. The buffer will be put at the head of the freelist. I don't think that the check makes any sense, but an equivalent already existed since the beginning: if (fs-fs_sbsize SBSIZE) bp-b_flags |= B_INVAL; brelse(bp); -- -- Michael van Elst Internet: mlel...@serpens.de A potential Snark may lurk in every tree.
Re: Removal of compat-FreeBSD
Greg Troxel wrote: Maxime Villard m...@m00nbsd.net writes: Apparently, compat-FreeBSD is needed by tw_cli users. Therefore I think I will just disable it by default in the GENERIC kernels, unless anyone disagrees. Our norms for significant changes are more or less about consensus or preponderance of opinion. So far you've said that you want to remove/disable this, and a number of people have said they use it. No one else has spoke up in favor of disabling. We don't have evidence that anyone (besides you) is disabling this in their kernels. So I think the opinions to date fall well short of enough to support even disabling by default. I find this offer to solve problems with FreeBSD-compat nerver-wracking. I would prefer to see solving it this way: - add FreeBSD-compat to the list of projects at the NetBSD website, - notify users and developers that FreeBSD-compat layer suffers from serious issues and is not usable and unmaintained, - notify that FreeBSD-compat development will be tracked for 3-6 months and if there nothing will considerably improve, it will be disabled and pushed to the queue of code-parts to be removed. With this approach of (somehow) sustainable development developers and users, those who care could plan their time of next projects for NetBSD without alarm to throw all their current works and put all hands on this or that. Personally, I can't start hacking on the FreeBSD-compat immediately, as there is a set of 5 patches waiting for peer-review and acceptance/ rejection from a NetBSD developer. Then it's a matter of days to submit next patches in the same field (some are already developed) and switch to usual projects.
Re: Removal of compat-FreeBSD
In article 20150213192419.gb5...@britannica.bec.de, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Fri, Feb 13, 2015 at 09:26:48AM -0500, Greg Troxel wrote: Maxime Villard m...@m00nbsd.net writes: Apparently, compat-FreeBSD is needed by tw_cli users. Therefore I think I will just disable it by default in the GENERIC kernels, unless anyone disagrees. Our norms for significant changes are more or less about consensus or preponderance of opinion. So far you've said that you want to remove/disable this, and a number of people have said they use it. No one else has spoke up in favor of disabling. We don't have evidence that anyone (besides you) is disabling this in their kernels. I have asked the same question a long time ago when we pruned a bunch of other obsolete emulations. From a security stand point, I fully agree with Maxime. The usefulness of the FreeBSD emulation is *very* limited, it can't even handle most FreeBSD 4 binaries. I find it highly questionable to keep a non-trivial attack surface for the sake of a single device driver, which most people likely don't even have. I don't see any evidence in the tree of COMPAT_FREEBSD improving or any of the users of tw_cli working on improving the situation by removing the need for it. As such I find disabling COMPAT_FREEBSD by default a very good idea for increasing the visibility of the problem. Maybe someone who should be caring actually starts to... I agree with joerg here. I think that reducing the footprint of GENERIC for the benefit of security is the right approach to this matter... We have the ALL kernel to test compilation, and the approach should be that GENERIC should be appropriate for all normal uses and I think COMPAT_FREEBSD belongs in the fringe users side (or at least in the limited number of users). I.e. If you want to run FreeBSD binaries, you can build your own kernel. christos
Re: A brelse() in FFS...
On 13 Feb 2015, at 19:18, Maxime Villard m...@m00nbsd.net wrote: Hi, this may be a stupid question; in ufs/ffs/ffs_vfsops.c, l.1153: if (fs-fs_sbsize SBLOCKSIZE) brelse(bp, BC_INVAL); else brelse(bp, 0); However 'fs-fs_sbsize' is *always* smaller than SBLOCKSIZE. So only the first branch is reached. It may be equal to SBLOCKSIZE. The BC_INVAL is here to not keep the buffer in cache. It may be read later with a size greater fs_sbsize and would break buffer cache invariance (blocks are always read with the same size). I don't understand what the BC_INVAL flag means, and its definition in sys/buf.h is not very enlightening: #define BC_INVAL0x2000 /* Does not contain valid info. */ Which branch do I keep? Both. -- J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
Re: Dealing with debugging macros for printing as part of aprint clean-up
In article 2015021322.g...@norite.fritz.box, Izaak yitz...@inbox.ru wrote: On Fri, Feb 13, 2015 at 05:17:24PM +, Christos Zoulas wrote: In article 20150208103806.ga1...@norite.fritz.box, Izaak yitz...@inbox.ru wrote: Having read through many files, I have found that often printf is wrapped in a macro like 'DPRINTF', which is occasionally used both in the driver attachment function and also elsewhere in the file. I am not sure whether to [...] suppose this question holds also for general macro usage, so what is the best way to deal with that? I think it is best to leave them alone too for now... I think that specifically for autoconfiguration it would be better to replace the debugging wrapper macro with the aprint_debug and aprint_debug_dev for attachment and then leave the macro in place for the rest of the file. I am only suggesting it because I have seen this in a few places already, so I am afraid if I leave it then the clean-up will leave behind many printf occurrences -- of course, those would be fixed in part 2 of the project anyway though. What do you think of that instead? Perhaps it is best to just change the printfs to aprint_debug_dev, but leave the other printf flavors (tprintf uprintf) alone? This at least will not change behavior? christos
Re: Removal of compat-FreeBSD
If you are going to disable COMPAT_FREEBSD in GENERIC kernels, then you probably also need to disable twe(4) and twa(4) as well. I would not be in favor of this. Several people have written saying they use tw_cli. I've not written, but I too use tw_cli to manage 3ware cards under NetBSD. I think a better fix would be to update the man pages so they document how fragile the FreeBSD compatibility code is. -thanks -Brian On Feb 13, 12:35pm, Maxime Villard wrote: } Subject: Re: Removal of compat-FreeBSD } Apparently, compat-FreeBSD is needed by tw_cli users. } } Therefore I think I will just disable it by default in the GENERIC kernels, } unless anyone disagrees. } } } } Le 07/02/2015 12:19, Maxime Villard a écrit : } Hi, } I intend to remove the compat-FreeBSD support from the system. } } It has a limited interest since no major proprietary software is developed on } FreeBSD; if one were, it would certainly be available on Linux, and we have full } compatibility support for that. } } You will also notice, after reading the code a bit, that our FreeBSD layer is } really poor: many syscalls are missing, the translation is not efficient, and } the layer is only available on i386. Recent FreeBSD-10 binaries often crash. } } Recently we found two enormous bugs so obvious and harmful that we should } normally have received a bug report from a user somewhere. We didn't, which } means that in 6 years nobody tested compat-FreeBSD - nobody being the } developers and the users. } } Clearly, we should not waste time and energy on something that simply does not } work. compat-FreeBSD could give the impression NetBSD has a reliable way to } execute FreeBSD binaries, which is far from being the case. } } This is what motivates my proposal. } } Ok? } } -- End of excerpt from Maxime Villard
Re: Removal of compat-FreeBSD
On Feb 13, 2015, at 2:14 PM, Christos Zoulas chris...@astron.com wrote: In article 20150213192419.gb5...@britannica.bec.de, Joerg Sonnenberger jo...@britannica.bec.de wrote: I have asked the same question a long time ago when we pruned a bunch of other obsolete emulations. From a security stand point, I fully agree with Maxime. The usefulness of the FreeBSD emulation is *very* limited, it can't even handle most FreeBSD 4 binaries. I find it highly questionable to keep a non-trivial attack surface for the sake of a single device driver, which most people likely don't even have. I don't see any evidence in the tree of COMPAT_FREEBSD improving or any of the users of tw_cli working on improving the situation by removing the need for it. As such I find disabling COMPAT_FREEBSD by default a very good idea for increasing the visibility of the problem. Maybe someone who should be caring actually starts to... I agree with joerg here. I think that reducing the footprint of GENERIC for the benefit of security is the right approach to this matter... We have the ALL kernel to test compilation, and the approach should be that GENERIC should be appropriate for all normal uses and I think COMPAT_FREEBSD belongs in the fringe users side (or at least in the limited number of users). I.e. If you want to run FreeBSD binaries, you can build your own kernel. Also, shouldn't the compat_freebsd module be autoloaded if you need it? If so, not having it in the kernel shouldn't really affect things.
Re: Interrupt storm mitigation needed
On Thu, Feb 12, 2015 at 09:02:37PM -0500, Thor Lancelot Simon wrote: On Thu, Feb 12, 2015 at 07:52:10PM +0100, Tom Ivar Helbekkmo wrote: Tom Ivar Helbekkmo t...@hamartun.priv.no writes: The uhci pins on the ioapics are chalking up a few interrupts, but not many, and no bursts. Still nothing bad happening, but I did reboot just now, and saw something that I've observered a few times lately: when the machine was just sufficiently up that I could log in, 'vmstat -i' told me that the ioapic pin for uhci2 had already generated slightly more than 21 interrupts. I guess the next question would then be whether, with uhci in polled mode, we can safely mask that pin. From what I see from the original message, there are two issues: (1) It's a shared interrupt. (2) uhci is generated interrupts when it should not. It's unlikely that we can do anything about (1), so I was trying to see if we can do something about (2). Note that this is not true polled mode in the sense of what is used during startup or in ddb. The next step would be to do some basic accounting of interrupt rate and if it is too high, turn off interrupt mask bits in uhci and switch to the callout. When it goes down again, re-enable normal interrupt mode. I'm not much in favour of doing the mitigation in the generic code as there are valid situations for getting more than 10k interrupts per second on a device -- older network cards without interrupt moderation for example. If that is the correct load, it is not a bug. Joerg
Re: Removal of compat-FreeBSD
Am 13.02.15 um 12:34 schrieb Maxime Villard: Le 09/02/2015 10:12, Marc Balmer a écrit : I intend to remove the compat-FreeBSD support from the system. [...] This is what motivates my proposal. Ok? Generally it would be a good idea, but there are obviously some tw_cli users. So they need a working alternative first, imo. Maybe 3Ware would help, if being asked? It is true that, now that tw_cli works on FreeBSD, little effort is required to make it work on NetBSD. Are you ready to ask 3Ware? That would not make sense, I don't have the hardware.
Re: Removal of compat-FreeBSD
On February 13, 2015 9:36:13 PM EST, Brian Buhrow buh...@nfbcal.org wrote: Hello. The point I was trying to make is that if you break COMPAT_FREEBSD by taking it out of the GENERIC kernel, you lose the ability to manage the twa(4) or twe(4) cards through the OS unless you recompile a kernel with COMPAT_FREEBSD back in. (Having an auto-loading module seems like it misses the point of enhancing security to me.). New users Sure, so perhaps the module shouldn't autoload, but that doesn't mean you need to recompile the kernel, just explicitly load the module (as root) if you need it. Taking it out of GENERIC doesn't make it impossible to load the module. Eric
Re: Dealing with debugging macros for printing as part of aprint clean-up
On Fri, Feb 13, 2015 at 10:17:29PM +, Christos Zoulas wrote: Perhaps it is best to just change the printfs to aprint_debug_dev, but leave the other printf flavors (tprintf uprintf) alone? This at least will not change behavior? Yes, that is what I was planning to do, thereby also following the advice of Martin. Changing the debugging DPRINTF for plain printf in attachment to aprint_debug seems reasonable to me. I will leave any other variant alone for now. -- Izaak
re: Dealing with debugging macros for printing as part of aprint clean-up
Christos Zoulas writes: In article 2015021322.g...@norite.fritz.box, Izaak yitz...@inbox.ru wrote: On Fri, Feb 13, 2015 at 05:17:24PM +, Christos Zoulas wrote: In article 20150208103806.ga1...@norite.fritz.box, Izaak yitz...@inbox.ru wrote: Having read through many files, I have found that often printf is wrapped in a macro like 'DPRINTF', which is occasionally used both in the driver attachment function and also elsewhere in the file. I am not sure whether to [...] suppose this question holds also for general macro usage, so what is the best way to deal with that? I think it is best to leave them alone too for now... I think that specifically for autoconfiguration it would be better to replace the debugging wrapper macro with the aprint_debug and aprint_debug_dev for attachment and then leave the macro in place for the rest of the file. I am only suggesting it because I have seen this in a few places already, so I am afraid if I leave it then the clean-up will leave behind many printf occurrences -- of course, those would be fixed in part 2 of the project anyway though. What do you think of that instead? Perhaps it is best to just change the printfs to aprint_debug_dev, but leave the other printf flavors (tprintf uprintf) alone? This at least will not change behavior? changing from DPRINTF() to aprint_debug*() will likely change the semantics. these debug messages will now trigger with boot -x, instead of a DEBUG kernel, won't they? that might be OK -- autoconf messages shouldn't happen normally, unlike other debug messages.. .mrg.
Re: Removal of compat-FreeBSD
Hello. The point I was trying to make is that if you break COMPAT_FREEBSD by taking it out of the GENERIC kernel, you lose the ability to manage the twa(4) or twe(4) cards through the OS unless you recompile a kernel with COMPAT_FREEBSD back in. (Having an auto-loading module seems like it misses the point of enhancing security to me.). New users with these cards might not then wish to use NetBSD with these cards simply because they don't want to go to the trouble of compiling a special kernel. We, as a NetBSD community, may have then lost those users, which I would see as unfortunate. -Brian On Feb 13, 9:25pm, Eric Haszlakiewicz wrote: } Subject: Re: Removal of compat-FreeBSD } On February 13, 2015 6:46:52 PM EST, Brian Buhrow buh...@nfbcal.org wrote: } If you are going to disable COMPAT_FREEBSD in GENERIC kernels, then } you probably also need to disable twe(4) and twa(4) as well. I would } not } be in favor of this. Several people have written saying they use } tw_cli. } I've not written, but I too use tw_cli to manage 3ware cards under } NetBSD. } } That's not at all the same. Code that can get triggered by an arbitrary executable has a very different attack surface than device drivers that won't be used if you don't have one of those devices in your system. } I'm all for trimming things down, but I don't think it's valid to claim that removing COMPAT_FREEBSD implies the need to remove anything else. } } Eric } } -- End of excerpt from Eric Haszlakiewicz
Re: Removal of compat-FreeBSD
In article 201502132346.t1dnkqgd005...@lothlorien.nfbcal.org, Brian Buhrow buh...@nfbcal.org wrote: If you are going to disable COMPAT_FREEBSD in GENERIC kernels, then you probably also need to disable twe(4) and twa(4) as well. I would not be in favor of this. Several people have written saying they use tw_cli. I've not written, but I too use tw_cli to manage 3ware cards under NetBSD. I think a better fix would be to update the man pages so they document how fragile the FreeBSD compatibility code is. This is a little severe. You can use the controller without tw_cli... christos
Re: Removal of compat-FreeBSD
On February 13, 2015 6:46:52 PM EST, Brian Buhrow buh...@nfbcal.org wrote: If you are going to disable COMPAT_FREEBSD in GENERIC kernels, then you probably also need to disable twe(4) and twa(4) as well. I would not be in favor of this. Several people have written saying they use tw_cli. I've not written, but I too use tw_cli to manage 3ware cards under NetBSD. That's not at all the same. Code that can get triggered by an arbitrary executable has a very different attack surface than device drivers that won't be used if you don't have one of those devices in your system. I'm all for trimming things down, but I don't think it's valid to claim that removing COMPAT_FREEBSD implies the need to remove anything else. Eric
Re: Removal of compat-FreeBSD
On Fri, Feb 13, 2015 at 07:05:00PM +0100, Maxime Villard wrote: Our norms for significant changes are more or less about consensus or preponderance of opinion. So far you've said that you want to remove/disable this, and a number of people have said they use it. No one else has spoke up in favor of disabling. Perhaps because I am the only one who read the code? I just read the code. What's so horrible about it? It's clearly old, and not very complete, but I don't see anything so terribly objectionable. (other than that all the syscall marshalling code should be autogenerated; but that's a topic for a different bikeshed) -- David A. Holland dholl...@netbsd.org
