Re: CVS commit: src
On Wed, Sep 02, 2015 at 03:49:22PM +, Christos Zoulas wrote: > In article <20150902134214.d867...@cvs.netbsd.org>, > Masao Uebayashi <source-changes-d@NetBSD.org> wrote: > > -#define CONFIG_VERSION 20150840 > +#define CONFIG_VERSION 20150841 > > This was supposed to be a date... When I introduced it my DNS-zone-file-encumbered head though of adding a couple 0s there to handle multiple versions within a day, but then I thought about it again and came to the conclusion that if I felt I needed to bump that number more than once in a day, it would mean that I'm not designing and/or developing correctly. I feel that conclusion still stands. -- 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. pgp50iV1lRllg.pgp Description: PGP signature
Re: CVS commit: src/usr.bin/config
On Fri, Aug 28, 2015 at 08:31:28AM +, Masao Uebayashi wrote: Module Name: src Committed By: uebayasi Date: Fri Aug 28 08:31:28 UTC 2015 Modified Files: src/usr.bin/config: mkmakefile.c Log Message: Accept only relative paths (from $S) for `file' and `object'. Simplify code. config(1) does not need to be super-smart about path handling, because it is usually used with make(1), that is much smarter. Pre-compiled object files, specified using `object', are regarded as read-only input, thus they should be put under $S (or $S/..), as part of a source tree. I'm pretty sure the original intent was to allow 3rd party drivers to be distributed as an object file and a relevant config(5) file to be included by the user in their GENERIC. Which is why all the definition gear is still allowed in the selection phase. That also mean that absolute paths for 'file' and 'object' have (had?) merit. So, if you're discarding that code (I haven't looked at the actual diff) you might want to consider bumping the syntax version and refusing older versions. That would probably get you some anger but hey, at this point for you it's probably a drop in the ocean :-) -- 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. pgpNp7AJzrQHS.pgp Description: PGP signature
Re: CVS commit: src/sys/kern
On Wed, Aug 19, 2015 at 02:05:33PM +1000, matthew green wrote: also: why did you not bring up this API change on tech-kern? I was going to say that needs-count needing to die is an old goal, but it turns out my config(5) is wrong and that defpseudo will not depend on needs-count being present to emit the number specified in the config. I'd argue that one thing that can be done is the following: - add needs-count to the current pseudo devices that do need the count - change the pseudodevinit() prototype to have no argument - change current pseudo devices that need the count to use the needs-count-generated #define instead of the parameter. - update config(1) to reflect that That way the pseudodev part of the equation is solved and all that will remain is for needs-count to be eliminated completely. -- 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. pgpmfjfMeJV56.pgp Description: PGP signature
Re: CVS commit: src/share/misc
On Fri, Apr 24, 2015 at 12:20:17AM +, Blue Rats wrote: Module Name: src Committed By: rodent Date: Fri Apr 24 00:20:17 UTC 2015 Modified Files: src/share/misc: acronyms Log Message: +BB = baby - with this commit, we document, rather than police, yet another acronym/abbreviation which is part of Internet culture. Those who feel otherwise are welcome to turn this over to core@, who resolve disputes among developers. It's part of a culture in some parts of the world to stone people to death for various actions you would not consider a crime. So the whole it's part of the culture thing is not a very satisfactory argument. Cultures evolve, and this is probably why you can enjoy your life the way it is. NetBSD doesn't have to show any support to the parts of the culture it doesn't like. The Internet offers many sources to decipher those acronyms so there is no need to give them any more credit than they are due. Freedom of expression means you can enjoy playing Cards against Humanity, but it doesn't mean it should be played with just anybody. Also, core@ is the technical lead of the project. This is more a membership@ thing. I actually looked at the bylaws yesterday if there was a way for the Foundation to revoke your membership but since your behaviour is just toxic and not illegal, there is little it could do. It surely is difficult to define what the NetBSD project likes or dislikes, but considering the feedback you have received until now, I would say it is pretty clear those commits were unwanted. Please consider how respectful said feedback has been so far, and while I am not worried about NetBSD, you should think about what it means for your own reputation in the long run. -- 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. pgpZaBhjbOu9F.pgp Description: PGP signature
Re: CVS commit: src/sys/dev
On Sat, Nov 01, 2014 at 07:54:18AM +, Masao Uebayashi wrote: Module Name: src Committed By: uebayasi Date: Sat Nov 1 07:54:18 UTC 2014 Modified Files: src/sys/dev: audio.c audio_if.h Log Message: Revert previous. Not only audio_attach_mi() but also audioprint() have to be separated. midi.c has the same problem, and a little more complicated. These will be revisited later. It's because they are functions for audiobus (where audio(4) attaches) rather than for audio. So you can split them into a file that depends on audiobus. Most pseudo-buses have that issue I think. Probably some actual buses too. I'd not really expect a kernel that has pchb but not pci selected to compile. -- 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. pgpvgghE0lLvC.pgp Description: PGP signature
Re: CVS commit: src/sys/dev
On Tue, Nov 04, 2014 at 01:16:40AM +0900, Masao Uebayashi wrote: On Mon, Nov 3, 2014 at 9:49 PM, Quentin Garnier c...@cubidou.net wrote: On Sat, Nov 01, 2014 at 07:54:18AM +, Masao Uebayashi wrote: Module Name: src Committed By: uebayasi Date: Sat Nov 1 07:54:18 UTC 2014 Modified Files: src/sys/dev: audio.c audio_if.h Log Message: Revert previous. Not only audio_attach_mi() but also audioprint() have to be separated. midi.c has the same problem, and a little more complicated. These will be revisited later. It's because they are functions for audiobus (where audio(4) attaches) rather than for audio. So you can split them into a file that depends on audiobus. Understood. Let me reprase: audiobus is already an interface attribute. Those functions (audio_attach_mi(), audioprint(), ...) will belong to audiobus.c (or .o, or .ko). Those drivers providing the audiobus interface (e.g. auich(4)) will depend on audiobus module. So: device auich: audiobus, ... The funny thing here is, the line has two meaning: a) providing audiobus interface, b) depending on audiobus module. Due to the limitation of the config(5) syntax! I don't see how this particular case is a problem. Why exposing an audiobus interface wouldn't imply depending on the audiobus-specific functions? One question is, when to unload audiobus-as-a-module. It is depended on by audio if drivers, but it does not depend on anything. When all audio if drivers are unloaded, there is not reason to keep it in kernel. Maybe some (smart) ref-counting is needed. So you moved on to loadable modules now? I thought your intent was .text massaging. Most pseudo-buses have that issue I think. Probably some actual buses too. I'd not really expect a kernel that has pchb but not pci selected to compile. I've not really looked into pseudos yet... I meant audiobus. There are a lot of such buses that are not really anything but a way to attach a generic device. -- 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. pgpbgQGnPOJZX.pgp Description: PGP signature
Re: CVS commit: src/usr.bin/config
On Thu, Oct 30, 2014 at 09:27:06PM +0900, Masao Uebayashi wrote: On Thu, Oct 30, 2014 at 8:36 PM, Alan Barrett a...@netbsd.org wrote: On Thu, 30 Oct 2014, Masao Uebayashi wrote: What do you expect by doing: options FOO no options FOO options FOO I expect it to be equivalent to just one options FOO. The no options FOO in line 2 should cancel the options FOO in line 1, and then the options FOO in line 3 should put it back. In the cases that I care about, the options and no options lines will be in different files, referenced via include directives. So, while you expect that options works before it's defined, you also expect the order is honored for no use. I'm not sure how it can work internally. At this moment, no are evaluated when it's parsed. Those no agp* fallouts happened because agp is re-selected while resolving dependency after all parsing is done. IMO anything relying on order tends to be broken by design. For example: if BAR depends on FOO, no options FOO has to disable BAR too, because BAR can't be enabled without FOO. But when you re-enable FOO, BAR is not enabled. Is this really what you're expecting? I don't know how it is right now, but options didn't use to depend on other options so with options the case is moot and I would expect the behaviour Alan describes as correct (this is how it worked the last time I touched config(1), or at least, was meant to work). For devices, I spent quite a bit of effort making sure no behaved the way Alan expects it. For instance: include GENERIC this* at pci? dev ? fun ? no device pci that* at pci? dev ? fun ? would emit an error for that* but not for this*. Moreover, without the last line, none of this* or anything pci-related in GENERIC would actually be selected. So if you start making defopt more equivalent to define and allow options BAR to depend on options FOO, then I would expect no options FOO to cancel a previous options BAR. Otherwise defopt and define used to have very different semantics. -- 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. pgpH8ruph4GRz.pgp Description: PGP signature
Re: CVS commit: src/sys/arch/i386/conf
On Sun, Aug 08, 2010 at 08:04:54PM +, Chuck Silvers wrote: [...] @@ -740,6 +740,10 @@ spdmem* at iic? addr 0x51 spdmem* at iic? addr 0x52 spdmem* at iic? addr 0x53 +spdmem* at iic? addr 0x54 +spdmem* at iic? addr 0x55 +spdmem* at iic? addr 0x56 +spdmem* at iic? addr 0x57 sdtemp* at iic? addr 0x18 You know, having more than one instance of any given attachment of a device in ALL is actually pointless: it doesn't change what gets compiled, and ALL is only a way to test compilation of as much of the kernel as possible. Not that it hurts in any way; it just doesn't change anything. (The se part of your commit was, of course, not pointless at all!) -- Quentin Garnier - c...@cubidou.net - c...@netbsd.org 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. pgpDSs1DLvt2D.pgp Description: PGP signature
Re: CVS commit: src/sys/arch
On Sat, Jul 24, 2010 at 04:49:28PM +0200, Matthias Drochner wrote: christoph_eg...@gmx.de said: How about making paddr_t always 64bit? That makes it much easier to deal with in libkvm. I don't think this is a good argument. The little gain of making a rarely used library like libkvm simpler can't justify adding overhead to the kernel. libkvm is hardly an issue. Kernel modules, on the other hand... PAE is a bridge technology, interesting only for few systems. Users of low-end i386 systems would be penalized, and most users of boxes with 4G memory would gain nothing because they run a 64-bit system anyway. So, imho, no kernel overhead is acceptable. Well, that's one opinion. My own, probably just as humble, is that such a gaping ABI incompatibility is completely unacceptable, especially after all the work that has been done to make some kernel subsystems a little bit more responsible regarding ABI. I'm really curious to see some actual measurements about that alleged overhead. The way I see it right now, we have a known lethal ABI incompatibility versus an alleged overhead of unknown size. -- Quentin Garnier - c...@cubidou.net - c...@netbsd.org 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. pgpz9dx02Z0SE.pgp Description: PGP signature
Re: CVS commit: src/sys/arch
On Sat, Jul 24, 2010 at 05:54:41PM +0200, Matthias Drochner wrote: c...@cubidou.net said: Kernel modules, on the other hand... Hmm, didn't think of that. (using them myself only for testing) a gaping ABI incompatibility is completely unacceptable There are two ways to fix this without the 64-bit-paddr overhead, a short-term and a long-term one. The short-term fix would be to use another module load path. This is close to calling it a different port, but it would not affect userland. A more correct but more expensive fix would be to keep out paddr_t from the kernel ABI relevant to modules. You won't keep bus_addr_t out of the ABI any time soon, so this is not a fix. Anyway, this is why I ask about measurements. That would at least allow a discussion based on facts instead of suppositions. -- Quentin Garnier - c...@cubidou.net - c...@netbsd.org 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. pgpmgDEIJOOfL.pgp Description: PGP signature
Re: CVS commit: src/sys/dev/acpi
On Mon, Jul 19, 2010 at 09:32:58AM +0300, Jukka Ruohonen wrote: On Sun, Jul 18, 2010 at 08:59:33PM -0400, Christos Zoulas wrote: 1. ACPI seems to define cpuids 1..n; we define 0..n-1. Adjust for that ACPI is silent about the CPU IDs in the processor object. In all three Huh? 8.4 Declaring Processors [...] When the platform uses the APIC interrupt model, OSPM associates processors declared in the namespace with entries in the MADT. Prior to ACPI 3.0, this was accomplished using the processor object's ProcessorID and the ACPI Processor ID fields in MADT entries. UID fields were added to MADT entries in ACPI 3.0. By expanding processor declaration using Device definitions, UID object values under a processor device are used to associate processor devices with entries in the MADT. This removes the previous 256 processor declaration limit. -- Quentin Garnier - c...@cubidou.net - c...@netbsd.org 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. pgpiWiBqs23aC.pgp Description: PGP signature
Re: CVS commit: src/games/factor
On Sun, May 16, 2010 at 02:10:35PM +0400, Aleksej Saushev wrote: [...] So nothing about algebra stops you factoring negative numbers. However, since the 'prime factors' should be prime numbers, they shouldn't include -1, but maybe the smallest factor should be negative. While it may be controversial whether to count 1 and -1 as prime, it is perfectly sensible to do so. I'm surprised to see so little common sense in all the discussions about factor(6). The reasons why 1, -1 or negative numbers are not defined as prime really is a matter of convenience. Think of all the theorems that start with let p be an odd prime, and now imagine what would happen to all other theorems involving primes if some numbers that are on the fence were added to the list. So really it's just a matter of making maths books thinner. The question you people should ask is not whether factor(6) is biblic^Wmathematically correct, but what definition of a prime number would make it most useful. I don't see why it would have to be the one found in algebra books. I can probably count the times I've used factor(6) with my fingers, and I'd be surprised if it wasn't also the case for all the people who shared a piece of their mind on the subject here. Heck, I'd bet some of you have posted more mails in those two threads than they had actual uses for factor(6) already. Honestly, I don't see anyone doing stricto sensu maths on a computer limiting their tools to NetBSD'd games.tgz. So factor(6) is a tool of very limited utility, a convenience that one uses only a few times and far-between. Therefore I think it is very arrogant to make it fail on any numerical input. The likely source for input for factor(6) is a cut-and-paste, or the end of a pipeline crunching some numbers. Do you really want to annoy the occasional users by making factor(6) something that is insulted that the user dared giving it 0, 1, or a negative number? All in all, it seems to me that Aleksej's position is probably the most practical one, therefore the most likely to be useful. -- Quentin Garnier - c...@cubidou.net - c...@netbsd.org 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. pgpcvRnMsgjVv.pgp Description: PGP signature
Re: CVS commit: src
On Fri, Mar 12, 2010 at 09:53:16PM +, Darran Hunt wrote: Module Name: src Committed By: darran Date: Fri Mar 12 21:53:16 UTC 2010 Modified Files: src/distrib/sets/lists/modules: mi src/external/cddl/osnet/dev/fbt: fbt.c src/external/cddl/osnet/dist/uts/common/dtrace: dtrace.c src/sys/modules/dtrace: Makefile src/sys/sys: module.h Added Files: src/sys/modules/dtrace/fbt: Makefile Log Message: DTrace: Add the Function Boundary Trace (FBT) provider moduile. This module instruments every function in the kernel with entry and exit probes. These probes are true zero-effect probes in that they don't exist in the code until they are enabled. The probes are enabled by directly patching the function entry and exit points to make jumps into the dtrace framework. This gives us over 29,000 trace points in the kernel. Amazing work! However, +#include machine/cpu.h +#include machine/cpufunc.h +#include machine/specialreg.h +#if 0 +#include x86/cpuvar.h +#endif +#include x86/cputypes.h + +#define ELFSIZE ARCH_ELFSIZE +#include sys/exec_elf.h As this is obviously MD code, the source should be organised in a way so that at least it is clear that the functionality is not available on archs other than i386 and amd64. -- Quentin Garnier - c...@cubidou.net - c...@netbsd.org 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. pgpl8ysX0gJ9S.pgp Description: PGP signature
Re: CVS commit: src/usr.bin/config
On Tue, Mar 02, 2010 at 10:10:15AM +0900, Masao Uebayashi wrote:
I'm considering to move cfdata[] and *_iattrdata to each driver's *.c.
Maybe
That would be a huge step back. Do *NOT* do that.
Oops. I meant s/cfdata/cfdriver/.
In the long run, templates are moved into *.c, and true configuration (direct
config / user config == cfdata) is loaded at run-time. Does this make sense?
That there should be a way to inject cfdata at run-time (well, along
with loading a module), yes.
That anything should be moved back to drivers' .c file, not really. The
information carried by a line like device pci { dev = -1,
function = -1 } is no different to a function prototype in a .h.
--
Quentin Garnier - c...@cubidou.net - c...@netbsd.org
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.
pgpk0pVG6ri3l.pgp
Description: PGP signature
Re: CVS commit: src/sys
On Sun, Feb 21, 2010 at 05:31:31AM +, Mindaugas Rasiukevicius wrote: Quentin Garnier c...@cubidou.net wrote: On Sun, Feb 21, 2010 at 02:11:40AM +, Darran Hunt wrote: Module Name: src Committed By: darran Date: Sun Feb 21 02:11:40 UTC 2010 Modified Files: src/sys/arch/i386/i386: trap.c vector.S src/sys/kern: kern_lwp.c kern_proc.c kern_synch.c src/sys/sys: lwp.h proc.h Added Files: src/sys/sys: dtrace_bsd.h Log Message: Add the DTrace hooks to the kernel (KDTRACE_HOOKS config option). Please defflag that option in conf/files and use the resulting include file as necessary. I think these #ifdefs for KDTRACE_HOOKS should be removed and empty stubs provided for no-DTrace case. Code will get cleaner and perhaps more modular. It's a different debate. If KDTRACE_HOOKS stays, it has to be defflag'd. -- Quentin Garnier - c...@cubidou.net - c...@netbsd.org 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. pgpuTwDwACT7N.pgp Description: PGP signature
Re: CVS commit: src/sys
On Sun, Feb 21, 2010 at 02:11:40AM +, Darran Hunt wrote: Module Name: src Committed By: darran Date: Sun Feb 21 02:11:40 UTC 2010 Modified Files: src/sys/arch/i386/i386: trap.c vector.S src/sys/kern: kern_lwp.c kern_proc.c kern_synch.c src/sys/sys: lwp.h proc.h Added Files: src/sys/sys: dtrace_bsd.h Log Message: Add the DTrace hooks to the kernel (KDTRACE_HOOKS config option). Please defflag that option in conf/files and use the resulting include file as necessary. -- Quentin Garnier - c...@cubidou.net - c...@netbsd.org 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. pgpJfg7miHoR2.pgp Description: PGP signature
Re: CVS commit: src/sys/dev/acpi
On Thu, Dec 03, 2009 at 04:18:52PM -0600, David Young wrote: On Thu, Dec 03, 2009 at 01:54:19PM -0800, Jason Thorpe wrote: On Dec 3, 2009, at 1:04 PM, Christoph Egger wrote: Module Name: src Committed By: cegger Date: Thu Dec 3 21:04:29 UTC 2009 Modified Files: src/sys/dev/acpi: acpi.c files.acpi Added Files: src/sys/dev/acpi: acpi_pci.c acpi_pci.h Log Message: Enumerate ACPI PCI devices. Allows to link PCI with ACPI devices. Patch presented on tech-kern@ http://mail-index.netbsd.org/tech-kern/2009/11/28/msg006552.html Shouldn't we just attach PCI busses @ ACPI instead of mainbus? ISTM that ACPI is a lot of things, but in this instance, it is hardware metadata. Existing practice notwithstanding, acpi is not a proper parent for any ISA/PCI device/bus driver. (The same goes for isapnp.) IMO, very few devices should attach at acpi, but autoconfiguration should use ACPI data, when it is available, for the direct configuration of devices that we would otherwise have to probe for. Was there ever a disagreement on that? I fail to see how the API that was just committed will not result in a #if NACPI 0 block every time it is used. -- Quentin Garnier - c...@cubidou.net - c...@netbsd.org 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. pgp2Botmh6Lmg.pgp Description: PGP signature
Re: CVS commit: src/etc/rc.d
On Fri, Sep 11, 2009 at 11:26:54PM +0200, Christoph Egger wrote: matthew green wrote: On Thu, 10 Sep 2009, Erik Fair wrote: On Sep 8, 2009, at 01:56, Christoph Egger wrote: Modified Files: src/etc/rc.d: network Log Message: Do not flush routes if root file system is nfs mounted. Fixes boot problem when the nfs server is in a different subnet. This change should be pulled up to netbsd-5. No, this change should be backed out, and the real problem (incorrect default for flushroutes) addressed in a different way. i agree. this is the 2nd time in recent history that controversial changes to rc.d have been commited without discussion. recent history has shown that patches got discussed after commit not before. Recent history has shown that you're not a stranger to committing convenience workarounds and then freely admitting that you have no complete grasp of the issue at hand. I'm not sure you want to continue on that slope. -- Quentin Garnier - c...@cubidou.net - c...@netbsd.org 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. pgpNFiyiFpYae.pgp Description: PGP signature
Re: CVS commit: src
On Sun, Sep 06, 2009 at 05:25:57PM +, Stephen Borrill wrote: [...] Log Message: hdaudio(4) is a standards-compliant driver for Intel High Definition Audio. It will replace azalia(4) after testing. To use, comment out azalia in your kernel configuration and uncomment the hdaudio and hdafg lines so it reads: Please make it the default. That's the way it will be in 6.0, so it will receive more immediate testing that way. -- Quentin Garnier - c...@cubidou.net - c...@netbsd.org 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. pgpoCUP0qi8Fg.pgp Description: PGP signature
Re: CVS commit: src/sys/net
On Tue, May 12, 2009 at 11:03:25PM +, Elad Efrat wrote: Module Name: src Committed By: elad Date: Tue May 12 23:03:25 UTC 2009 Modified Files: src/sys/net: if_bridge.c Log Message: Move kauth(9) call before going into splnet(). Mailing list reference: http://mail-index.netbsd.org/tech-net/2009/05/08/msg001286.html So, 1. You commit without anybody having ok'd it 2. You don't commit the patch that you sent 3. When (publicly, even) told about an obvious bug, you still go ahead and commit it. Considering your work is related to security, you should really reconsider your methods, Elad. (And thank Christoph for the fix.) -- Quentin Garnier - c...@cubidou.net - c...@netbsd.org 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. pgppt3UB6Poc7.pgp Description: PGP signature
Re: CVS commit: src/sys/net
On Sun, May 17, 2009 at 05:40:44PM +0300, Elad Efrat wrote: [...] 3. When (publicly, even) told about an obvious bug, you still go ahead and commit it. False, the bug you're referring to wasn't the one that was fixed, see the commit diff: http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/net/if_bridge.c.diff?r1=1.68r2=1.69f=h Yes, it's much different; instead of dereferencing crap because of an invalid value of ifd_cmd, you were dereferencing NULL beacause of an invalid value of ifd_cmd. What's really worse, though, is that gcc *told* you about bc being used uninitialised, which I guess is why you added the XXXGCC comment at the initialisation of bc. So, really, Elad, reconsider the way you do security development. -- Quentin Garnier - c...@cubidou.net - c...@netbsd.org 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. pgpCEw7Ey4rvl.pgp Description: PGP signature
Re: CVS commit: src/sys/dev/dec
On Tue, May 12, 2009 at 04:24:07PM +0100, Robert Swindells wrote: Valeriy E. Ushakov wrote: On Tue, May 12, 2009 at 14:18:16 +, Christoph Egger wrote: struct device * - device_t, no functional changes intended. Why don't you cmp(1) the objects before and after to verify that? Same object code generated is, unlike intentions, something that can be verified. A fair number won't be the same, I would guess half our SCSI drivers are currently broken. Do a search in sys/dev/ic for 'adapt_dev', any driver that casts this to a softc instead of calling device_private() will crash. As much as I dislike the way cegger does those changes, that's simply not true. -- Quentin Garnier - c...@cubidou.net - c...@netbsd.org 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. pgprgCXgNJjkc.pgp Description: PGP signature
Re: CVS commit: src/sys/dev/dec
On Tue, May 12, 2009 at 05:15:05PM +0100, Robert Swindells wrote: Christoph Egger wrote: Valeriy E. Ushakov wrote: On Tue, May 12, 2009 at 14:18:16 +, Christoph Egger wrote: struct device * - device_t, no functional changes intended. Why don't you cmp(1) the objects before and after to verify that? Same object code generated is, unlike intentions, something that can be verified. A fair number won't be the same, I would guess half our SCSI drivers are currently broken. Do a search in sys/dev/ic for 'adapt_dev', any driver that casts this to a softc instead of calling device_private() will crash. The cast is a bug in drivers which have the device_t/softc split already done. It is harmless for those not yet splitted. Maybe ahc(4) was the only one that was broken. The point is that you could have found this by comparing the object files. Ok, so, just to clarify: - changing struct device * to device_t is pure cosmetics - problem arise with botched device_t/softc split, which is a different thing, and *is* a functional change. That means that cegger *did* break ahc when he did the split for ahc, so thank you for fixing it. Now, of course, that doesn't come as a surprise. Some people just never learn or listen. Or apologise. -- Quentin Garnier - c...@cubidou.net - c...@netbsd.org 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. pgpOYbynUv7IW.pgp Description: PGP signature
Re: CVS commit: src/sys/netinet
On Tue, May 12, 2009 at 09:48:42PM +, Elad Efrat wrote: Module Name: src Committed By: elad Date: Tue May 12 21:48:42 UTC 2009 Modified Files: src/sys/netinet: ip_carp.c Log Message: Fix inverted permissions check. - if ((l == NULL) || (error = kauth_authorize_network(l-l_cred, + if ((l != NULL) || (error = kauth_authorize_network(l-l_cred, That can't be right. If l is NULL, then it should be dereferenced? Is there a contest for tree breakage these days? -- Quentin Garnier - c...@cubidou.net - c...@netbsd.org 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. pgp06wENPfl9k.pgp Description: PGP signature
Re: CVS commit: src/sys/conf
On Wed, May 06, 2009 at 01:42:06PM +1000, matthew green wrote: Module Name: src Committed By: cube Date: Wed May 6 02:52:13 UTC 2009 Modified Files: src/sys/conf: files Log Message: Bump required config(1) version after files.drm changes [hi mrg!]. so, this is because i'm using the new feature you added, for the first time in our tree? Yes. I could have added the line only to files.drm but doing this can have side-effects when people forget about it and new versions of the config syntax come along. -- Quentin Garnier - c...@cubidou.net - c...@netbsd.org 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. pgpWYOFBJdPUr.pgp Description: PGP signature
