Re: Inter-driver #if dependencies
On Thu, May 21, 2015 at 11:25:03AM +0800, Paul Goyette wrote: > On Tue, 19 May 2015, Quentin Garnier wrote: > > > On Tue, May 19, 2015 at 12:12:17AM +, Taylor R Campbell wrote: > >>Date: Tue, 19 May 2015 06:57:44 +0800 (PHT) > >>From: Paul Goyette [...] > >> But I'm not sure a generic autoconf mechanism is warranted for such > >> glue. Better to identify working solutions for specific cases and > >> then generalize, rather than start with a super-generic mechanism > >> before it has been demonstrated to work well in any specific case. > > > > I think a generic autoconf mechanism would be welcome to be able to > > discover devices and walk down a firmware-provided device tree at the > > same time. That would save a lot of the register_device(9) (or > > whatever that API is called) magic where every time the arch-specific > > code has to enumerate the device tree to find the matching device and > > get information. > > register_device(9) == config_found_ia() perhaps I meant device_register(). It's an arch-dependent callback called after each attach. Look at what the archs that implement it do with it. If somehow autoconf(9) could interface with an essentially MD device tree, it would simplify a lot all that code. Back when I was thinking about autoconf(9), I had 3 main goals: - don't do recursion, which means that instead of having config_found(9) try and attach a driver, the parent will just get a device_t back, which is all it needs, and later autoconf(9) will see if it can attach a driver to it, and so on. It makes direct configuration buses a lot saner (and think in terms of loadable modules too). And of course it's easier on the stack. - allow for something you could call a co-driver. A piece of code that would attach to an aspect of a piece of hardware. Look at all the PCI-to-PCI or LPC bridges in the x86 world to see where that comes from. - allow descending a MD device tree along with the device discovery done by drivers through autoconf(9) -- 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. pgpg8SL_xEUIX.pgp Description: PGP signature
Re: Inter-driver #if dependencies
On Tue, May 19, 2015 at 12:12:17AM +, Taylor R Campbell wrote: >Date: Tue, 19 May 2015 06:57:44 +0800 (PHT) >From: Paul Goyette > >On Mon, 18 May 2015, Masao Uebayashi wrote: > >> How about: >> >> - making pcppi(4) provide the new pcppibus(4), and >> - making attimer(4) and pckbd(4) attach at pcppibus(4) > >A couple of issues with this approach: > >* pckbd already attaches at an unrelated parent, pckbc >* attimer can attach currently at acpi, as well as at isa > >The real problem here is that these other drivers, whether they're >children of pcppi or of something else, are optional. And their very >presence, whether or not any instance is actually configured, (and >without regard to where they are attached) changes the behavior of >pcppi. > > Can you explain how the devices are actually related, both in the > hardware and in the kernel representations of it, irrespective of how > it is currently manifested in autoconf? IIRC, for attimer(4) and pcppi(4), they share register space. They appear as distinct devices in ACPI trees though so it makes things interesting. > Sometimes there is a non-tree relation between two devices in a piece > of physical hardware which both hang off a generic bus that ought not > to have device-specific hacks to make the two talk. E.g., the HD > audio and graphics devices on current Intel PCI buses exhibit this. It's even worse in the eval board world where some devices depend on muxes or clocks being set up correctly, and those appear in very different area of the device tree. > But I'm not sure a generic autoconf mechanism is warranted for such > glue. Better to identify working solutions for specific cases and > then generalize, rather than start with a super-generic mechanism > before it has been demonstrated to work well in any specific case. I think a generic autoconf mechanism would be welcome to be able to discover devices and walk down a firmware-provided device tree at the same time. That would save a lot of the register_device(9) (or whatever that API is called) magic where every time the arch-specific code has to enumerate the device tree to find the matching device and get information. It's a rather difficult problem though. -- 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. pgpCeu5kYPUcS.pgp Description: PGP signature
Re: i386 vs radeondrmkms problem - isa attachments suck
On Mon, Mar 02, 2015 at 01:08:04PM +, David Brownlee wrote: > On 28 February 2015 at 09:44, matthew green wrote: > > > > > > hi folks. > > > > i've been trying to find a least-ugly solution to the radeondrmkms > > on i386 problem. quick summary of what's wrong: > > > > radeondrmkms doesn't complete attachments (and most > > importantly create a wsdisplay) until mountroot completes. > > this means it happens quite late in boot. in i386 GENERIC, > > vga@isa and pcdisplay@isa are still enabled and they will > > attach to the legacy vga device, and present a wsdisplay0 > > to the system. later, radeon0 attaches, and we get a > > wsdisplay1 that has taken over the console output. > > > > this leaves us with a non-working console output, and the inability > > to run X11 even if accessed remotely. > > > > my first attempt (that is currently commited), made the radeondrmkms > > driver attempt to map the isa vga registers to reserve them from the > > vga@isa, and while that worked on my serial console machine, it does > > not work on a normal system due to x86 consinit() attaching the > > basic vga console driver (so we get early console output.) in this > > case, it has already mapped these registers (ie, radeon is unable > > to map them) and the later real attachment knows not to attempt it > > again. so that method doesn't work. > > > > we could have the vga driver detach itself at the right point, but > > that leaves the console detached for quite a while, during the time > > that drm is getting setup (ie, we'd miss several of its early > > messages.) that seems less than desireable. > > > > it was suggested having a fake driver to attach instead of vga and > > thus avoiding the second phase of vga attachment, however this does > > not work due to the way isa indirect attachment works. the first > > match routine that returns non-zero is attached, and the order of > > routines called seems to be something config(1) generates. so having > > a radeon@isa that returns a history priority does nothing if the > > ordering is bad. this means that the current expectation of eg, > > the vga@isa vs pcdisplay@isa drivers (where vga returns a higher > > match) is not used, it just happens that the cfdata[] array has the > > vga@isa entry before pcdisplay@isa. > > Is the ignoring of attach priority a general characteristic of > indirect buses, and might it make sense for config to be able to > explicitly prioritise the order the cfdata[] entries? I know uebayasi@ > has been rototilling config and wondered if he could be interested... > :) The problem is that there is no notion of priority for indirect buses because it is up to the attaching driver to determine if it should attach or not. You could imagine working around that by adding code to check whether two drivers claim conflicting resources, and then the idea of priority would work. GSoC project maybe? > > this is not a problem for the old drm code, as it does not create > > wsdisplay itself, but relies on the vga driver to do so. > > > > (see isa.c:isasearch() config_match*() call for where the first match > > to return non-zero is used.) > > > > any one have any other ideas? at this point to make DRMKMS work for > > i386 on -7, i think we may have to createa a LEGACY kernel that has > > the vga|pcdisplay@isa drivers (and probably no drm at all?), and turn > > these devices off in GENERIC itself, but perhaps someone has a less > > ugly idea. I'd actually create a i386-legacy arch and get rid of all the crud in i386 that deals with stuff built before 2005 or so. And move that to tier-infinity and let it die peacefully. -- 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. pgpQX22r_Z7Ki.pgp Description: PGP signature
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 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: ubc_uiomove returns EINVAL
On Fri, Oct 24, 2014 at 01:19:01PM +, Emmanuel Dreyfus wrote: > On Fri, Oct 24, 2014 at 03:36:39PM +0700, Robert Elz wrote: > > That you are seeing it on i386 makes it less likely to be system > > specific (though because those two share so much, does not rule it out.) > > It happens in kcopy, an assembly language routine, in which I do not > see how we can get EINVAL returned. > > The backtrace is: > kcopy > uiomove > ubc_uiomove kcopy faults and EINVAL come from uvm_fault? You'll have to look there. -- 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. pgpAqL9QVuCmH.pgp Description: PGP signature
Re: log(9) variant for device error messages
On Mon, Jun 16, 2014 at 08:10:28AM -0700, Brian Buhrow wrote: > Hello. Perhaps my question is naive, but why does there need to be a > distinction between what log_dev() and aprint_*() do? Why not just change > aprint_* functions under the hood to use the log facilities of the kernel > as appropriate. then as a device driver writer, I don't need to change my > code to keep it working in the netbsd tree nor do I need to worry about > when which is appropriate to use. Adding a new logging function wich is > essentially the same as a function as is already being used, I'm talking > from a users' perspective, not a technical perspective, seems like a lot of > unnecessary code churn for very little gain. As long as I know how to make > the kernel squawk when I need it to, I don't much care if it uses log() or > printf(), so long as the messages get to a place where I can see them. > Ok, there, I've asked. I'm prepared to be enlightened as to the error > of my ways. Lol. When I say "retire", I mostly mean "stop documenting". As you point you, there is little point (beside annoying people) in removing the aprint_* API. But if it could gently be pushed out to the retirement castle, I wouldn't mind the slightest. -- 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. pgpjc5dmAjpt3.pgp Description: PGP signature
Re: log(9) variant for device error messages
On Mon, Jun 16, 2014 at 03:48:37PM +0200, Martin Husemann wrote: > The aprint_error_dev() function is probably one of the most abused aprint_* > family functions in drivers, because it is SO usefull. > > However, the abuse of aprint_* for messages past autoconfiguration has to > stop. It would be good to have a good replacement in the log(9) family. > > So I propose to create > > void log_device_error(device_t, const char *format, ...); > > which prepends the message with device_xname() and ": ", and passes it > as LOG_ERR to log(9). > > What do you think? I think instead, we could have void log_dev(device_t dev, int level, const char *format, ...); and retire aprint_*. In these days of interrupts being activated early and kernel modules, there isn't a specific time for autoconfiguration any more. log(LOG_ERR) can set the same flag aprint_error sets for init(8) to know something unexpected happened before it was loaded, however useful that is. Then there is the question of aprint_naive(9) but if you ask me I could do without AB_QUIET anyway. The time to stare at the console while the computer boots is long gone, so AB_SILENT, AB_NORMAL and AB_DEBUG cover all the reasonable uses in my very humble opinion. -- 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. pgpY_Co2qt0dX.pgp Description: PGP signature
Re: Modules loading modules?
On Sun, Aug 01, 2010 at 06:05:20PM -0700, Paul Goyette wrote:
> On Mon, 2 Aug 2010, Quentin Garnier wrote:
>
> >>+int
> >>+rmutex_tryenter(rmutex_t *rmtx)
> >>+{
> >>+ int rv = 1;
> >>+
> >>+ if (mutex_owned(&rmtx->rmtx_mtx)) {
> >>+ rmtx->rmtx_recurse++;
> >>+ KASSERT(rmtx->rmtx_recurse != 0);
> >>+ } else if ((rv = mutex_tryenter(&rmtx->rmtx_mtx)) != 0) {
> >>+ rmtx->rmtx_recurse++;
> >>+ KASSERT(rmtx->rmtx_recurse != 0);
> >>+ }
> >>+ return rv;
> >>+}
> >
> >I am probably not getting the idea, but I fail to see how this qualifies
> >as a mutex. My reading of this piece of code is that rmutex_enter() is
> >always going to succeed immediately.
>
> According to the mutex(9) man page:
>
> mutex_owned(mtx)
>
>For adaptive mutexes, return non-zero if the current LWP holds
>the mutex. ...
Ah, that was what I was missing. Thanks.
--
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.
pgp0WclWeuAf7.pgp
Description: PGP signature
Re: Modules loading modules?
On Sun, Aug 01, 2010 at 05:17:01PM -0700, Paul Goyette wrote:
[...]
> +void
> +rmutex_enter(rmutex_t *rmtx)
> +{
> + if (mutex_owned(&rmtx->rmtx_mtx)) {
> + rmtx->rmtx_recurse++;
> + KASSERT(rmtx->rmtx_recurse != 0);
> + } else {
> + mutex_enter(&rmtx->rmtx_mtx);
> + rmtx->rmtx_recurse = 1;
> + }
> +}
> +
> +void
> +rmutex_exit(rmutex_t *rmtx)
> +{
> + KASSERT(mutex_owned(&rmtx->rmtx_mtx));
> + KASSERT(rmtx->rmtx_recurse != 0);
> + if (--rmtx->rmtx_recurse == 0)
> + mutex_exit(&rmtx->rmtx_mtx);
> +}
> +
> +int
> +rmutex_tryenter(rmutex_t *rmtx)
> +{
> + int rv = 1;
> +
> + if (mutex_owned(&rmtx->rmtx_mtx)) {
> + rmtx->rmtx_recurse++;
> + KASSERT(rmtx->rmtx_recurse != 0);
> + } else if ((rv = mutex_tryenter(&rmtx->rmtx_mtx)) != 0) {
> + rmtx->rmtx_recurse++;
> + KASSERT(rmtx->rmtx_recurse != 0);
> + }
> + return rv;
> +}
I am probably not getting the idea, but I fail to see how this qualifies
as a mutex. My reading of this piece of code is that rmutex_enter() is
always going to succeed immediately.
Please correct me if I'm wrong--and I am very probably wrong--, but
isn't the point of a recursive mutex to allow the thread initially
taking the mutex to take it again, but not other threads? The code
would have to be a lot more complicated than that.
All I see here is a fancy no-op, but maybe it's just me.
--
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.
pgpgTt12zdsHJ.pgp
Description: PGP signature
Re: pchb@acpi
On Sun, Aug 01, 2010 at 11:17:54PM +0900, KIYOHARA Takashi wrote: > Hi! all, > > > I want p...@acpi support. > > All recent PC has information on PCI in ACPI. > We can attach pchb in acpi like a lot of other acpi devices. > p...@acpi has been fairly supported in FreeBSD since before. > > ftp://ftp.netbsd.org/pub/NetBSD/misc/kiyohara/ia64/p...@acpi-support.diff Do you have anything further in mind? This patch is only dmesg cosmetics. -- 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. pgpAmChueJoUZ.pgp Description: PGP signature
Re: RFC: device flavours
On Wed, Jul 28, 2010 at 11:00:58AM -0500, David Young wrote: > On Wed, Jul 28, 2010 at 03:09:36PM +0000, Quentin Garnier wrote: > > On Tue, Jul 27, 2010 at 09:23:04AM +0200, Martin Husemann wrote: [...] > > > FWIW, what David outlines is pretty close to the way i2c direct config > > > works in -current. > > > > Your point is? In David's scheme, the ichlpc driver has to do the work > > to attach the pcib driver and said work has to be replicated in every > > other variant, and you still need a generic variant to attach the actual > > pcib driver when none of the *pcib drivers match. > > Replicating the work of attaching a pcib(4) in the variant drivers is > not so much work. But then, status quo is even less, and not that different. It's funny how things go. My intent was to provide a new tool, and to show an example of a situation where said tool is less of a kludge, more module- friendly and so on. And now some people thinks I'm focused on that particular issue. But if I hadn't given any example, I'm sure people who have stopped right away at what would have seem like a complete shot in the dark. > > And after that, the > > pcib driver will have to know that it might be on an ACPI system and > > thus can fetch information there. Think what you want, but to me it is > > nonsense and that's exactly what I am trying to find a solution to here. > > The pcib(4) driver only needs to attach its isa(4). isa(4) need not know > anything about ACPI, it just walks its MI device properties list to see > what is directly configurable. > > I don't understand why isa(4) was out of the picture in your flavors > proposal. It's a corner that I've cut; I had the acpinodebus attachments so I used them, for the sake of the example. I could have taken that bit from Jared's old patch (although I dislike using the same match function for both direct and indirect configuration, but then it's not like autoconf(9) leaves any room there), but, really, it wasn't the point. I've cut a lot of other corners in that patch. -- 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. pgpC4khSyt1Bx.pgp Description: PGP signature
Re: RFC: device flavours
On Tue, Jul 27, 2010 at 09:23:04AM +0200, Martin Husemann wrote: > On Tue, Jul 27, 2010 at 01:56:23AM +0000, Quentin Garnier wrote: > > "For free" is a subjective thing. I don't think using device_register() > > --which is a MD callback--to pass information between two MI drivers is > > free. > > Well, using a MD callback to attach MD information from ACPI somehow > makes sense to me. Information is just what it is, information. It becomes MD only when something tries to interpret it, and that's the job of the ISA backend through the bus_space functions and the interrupt stuff. > FWIW, what David outlines is pretty close to the way i2c direct config > works in -current. Your point is? In David's scheme, the ichlpc driver has to do the work to attach the pcib driver and said work has to be replicated in every other variant, and you still need a generic variant to attach the actual pcib driver when none of the *pcib drivers match. And after that, the pcib driver will have to know that it might be on an ACPI system and thus can fetch information there. Think what you want, but to me it is nonsense and that's exactly what I am trying to find a solution to here. -- 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. pgp4aKiYR4Vh7.pgp Description: PGP signature
Re: RFC: device flavours
On Mon, Jul 26, 2010 at 06:27:55PM -0500, David Young wrote: > On Sun, Jul 25, 2010 at 09:22:53PM +0000, Quentin Garnier wrote: > > Hi all, > > > > I'm looking for comments about what I call "device flavours". The best > > example of the kind of situation it tries to be an answer for is the > > multiplicity of drivers one can find around the source tree for PCI-ISA > > bridges (mostly on x86). An even older idea of mine is to finally see > > legacy devices listed in the ACPI tables attached to the PCI-ISA bridge > > where they logically belong, and device flavours can be used for that, > > too. > > > > Here's an exerpt of the dmesg output I get on my EeeBox, with two > > flavours defined, ichlpc (to replace ichlpcib(4)) and acpiib (to let > > legacy devices attach there; I've only let npx(4) attach though for the > > sake of the test): > > > > pcib0 at pci0 dev 31 function 0: vendor 0x8086 product 0x27b9 (rev. 0x02) > > timecounter: Timecounter "pcib0/ichlpc" frequency 3579545 Hz quality 1000 > > pcib0/ichlpc: 24-bit timer > > pcib0/ichlpc: TCO (watchdog) timer configured. > > gpio5 at pcib0: 64 pins > > pcib0/acpiib: ACPI node SBRG > > npx1 at pcib0 (COPR, PNP0C04): io 0xf0-0xff irq 13 > > npx1: reported by CPUID; using exception 16 > > SIOR (PNP0C02) at pcib0 not configured > > RMSC (PNP0C02) at pcib0 not configured > > OMSC (PNP0C02) at pcib0 not configured > > ISTM you can accomplish about the same thing and get the pmf(9) support > "for free" with a slightly different approach: > > 0) Extract ISA "direct configuration" information from ACPI tables (and >ISA Plug 'N' Play?) and stuff it somewhere that device_register(9) >can get it. > > 1) Make device_register() attach ISA direct configuration information to >each isa(4) instance as device properties. > > 2) Make isa(4) use direct configuration if the information is available in >device properties. > > 3) Refactor ichlpcib0 and pcib0 so that you have > ichlpc0 at pci0 dev 31 function 0: ... > timecounter: Timecounter "ichlpc0" frequency 3579545 Hz quality 1000 > ichlpc0: 24-bit timer > ichlpc0: TCO (watchdog) timer configured. > pcib0 at ichlpc0: ... > isa0 at pcib0: ... > gpio5 at ichlpc0: 64 pins > npx0 at isa0: ... > > ISTM that following such an approach, you get pmf(9) support and > detachment virtually for free. "For free" is a subjective thing. I don't think using device_register() --which is a MD callback--to pass information between two MI drivers is free. Nor the fact that you end up with three full devices in your tree when there is only one in the ACPI tree. You know, I've been there before: http://mail-index.netbsd.org/tech-kern/2005/11/11/0011.html And then Jared had his own approach a couple years later (which I'm not a big fan of, but still looks a lot nicer than using device_register()): http://mail-index.netbsd.org/tech-kern/2007/11/21/0010.html -- 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. pgpCh5aNhRQm1.pgp Description: PGP signature
Re: RFC: device flavours
On Mon, Jul 26, 2010 at 08:25:10AM +0300, Jukka Ruohonen wrote: > On Sun, Jul 25, 2010 at 09:22:53PM +0000, Quentin Garnier wrote: > > bridges (mostly on x86). An even older idea of mine is to finally see > > legacy devices listed in the ACPI tables attached to the PCI-ISA bridge > > where they logically belong, and device flavours can be used for that, > > too. > > I am not sure if I understand all of this, so bear with me. > > While this is the direction we should go, it seems to me that the long- That's a bold statement that I wouldn't have dared say :-) > standing issues in ACPI-PCI-ISA are not so much where the legacy drivers > actually logically attach, but that these, like majority of drivers on > modern x86, should utilize the information from ACPI. Sure. The ISA_DIRECT_CONFIG() macro is a kludge to allow direct configuration on the ISA bus. I could have fetched Jared McNeill's old patch that implemented direct configuration of the legacy devices using that (and he and I would certainly have had a good laugh about it), but here it was simpler to simply have an acpinodebus and attach the driver under dev/acpi. But here you get into autoconf(9) issues that are outside the scope of this thread. My long standing opinion is that drivers should have the possibility to have both a probe function (for indirect configuration) and a match function (for direct configuration). And even when you have that, at what point should the ACPI resources be decoded? The driver itself could still do it, in which case it wouldn't really be different from the current situation. > Is this possible with flavours? Will the siblings still require a stub on > the ACPI side of things? I think it is an orthogonal issue. The point of the flavours here for ACPI was to allow mixing the features without invading the *pcib drivers. > > pcib0 at pci0 dev 31 function 0: vendor 0x8086 product 0x27b9 (rev. 0x02) > > timecounter: Timecounter "pcib0/ichlpc" frequency 3579545 Hz quality 1000 > > pcib0/ichlpc: 24-bit timer > > pcib0/ichlpc: TCO (watchdog) timer configured. > > gpio5 at pcib0: 64 pins > > pcib0/acpiib: ACPI node SBRG > > npx1 at pcib0 (COPR, PNP0C04): io 0xf0-0xff irq 13 > > npx1: reported by CPUID; using exception 16 > > SIOR (PNP0C02) at pcib0 not configured > > RMSC (PNP0C02) at pcib0 not configured > > OMSC (PNP0C02) at pcib0 not configured > > In the above example it is known that the LPC bridge currently conflicts > with the ACPI PM registers. So to put this to the logical end, the > derivation using ACPI should start from there, and the pci_mapreg_map(9) > call therein should use the information supplied by ACPI. That's entirely possible, and it is the kind of reasons why I have the pre-attach call to the flavours. The fact that the main driver doesn't have to know about the flavours doesn't mean they can't communicate, and for instance the flavour can set a device property. > > There are other situations in which I think device flavours could bring > > clarity and also better modularisation. For instance, support for CPU > > features on x86 like EST or PowerNow, or even ACPI P-states could be > > done that way, and it is more module-friendly because it wouldn't > > require the main CPU driver to explicitely call those feature-drivers. > > Here I can see use. I was actually seeking this kind of granularity with the > ACPI CPU. Well, I'm sure you know how I feel about having a cpu(4) object somewhere in the device tree and an acpicpu(4) object somewhere else. -- 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. pgpMIxGKpxIXO.pgp Description: PGP signature
Re: RFC: device flavours
On Sun, Jul 25, 2010 at 05:54:01PM -0400, der Mouse wrote: > > I'm looking for comments about what I call "device flavours". [...] > > I'm having trouble seeing what this offers over things (like scsibus) > where an abstraction attaches at real hardware and then other things > attach to the abstraction. It seems to me that scsibus serves a different purpose, but yes, it is surely possible to achieve similar results using the current autoconf(9) and probably abusing it in various ways. > > flavour acpiib at pci: acpinodebus > > filedev/acpi/acpiib.c acpiib > > > > flavour ichlpc at pci: acpipmtimer, sysmon_wdog, fwhichbus, hpetichbus, gp= > > iobus > > filearch/x86/pci/ichlpc.c ichlpc > > > flavours ichlpc, acpiib > > npx*at pcib? > > gpio* at gpiobus? > > > I've been wondering about simply allowing more than one driver to > > attach to a device, > > It seems to me that we already have something effectively the same as > that, mediated by a "controller" driver. For example, consider the > way, on sparc, zs attaches to the chip and then zstty or kbd or ms > attaches to zs (or at least that's how it used to work). The interaction between zs and zstty looks to me like plain regular direct configuration, with zs enumerating features. > You write that > > > But the main point is that a flavour can be created without the main > > driver being aware of it; > > but, again, it looks to me as though we already have that: to return to > the zs example, the zs code does not need to know anything about the > list "zstty, kbd, ms" in order for those child devices to work. It has to know the features (and yes, calling them devices would be somewhat incorrect) exist, even if it doesn't know their purpose. > But I feel certain you are already familiar with all that. So I must > be missing something. What? My explanations are certainly most unclear; I think the point of the flavours is to add a bit of indirect configuration over a direct configuration bus. The way I understand zs(4) works, the zs device serves as an enumerator of a list of features. The intended purpose of the flavours is indeed to push that kind of behaviour back into the configuration framework. Now, I don't think they're entirely swapable, especially not in the example I give. Part of the difference between zs(4) and the pcib(4) case is that in the former case, the features are not terribly different from one another, or at least not different enough to warrant a different interface attribute. In the pcib(4) case, the features are logically at complete odds, and having them as children enumerated by a "controller" pcib driver would mean pushing a lot of knowledge about they work into said controller driver. With the flavours, pcib(4) doesn't have to do anything but attach the isa(4) bus. Does that clear things a little? -- 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. pgpcfPxnNySo1.pgp Description: PGP signature
RFC: device flavours
Hi all, I'm looking for comments about what I call "device flavours". The best example of the kind of situation it tries to be an answer for is the multiplicity of drivers one can find around the source tree for PCI-ISA bridges (mostly on x86). An even older idea of mine is to finally see legacy devices listed in the ACPI tables attached to the PCI-ISA bridge where they logically belong, and device flavours can be used for that, too. Here's an exerpt of the dmesg output I get on my EeeBox, with two flavours defined, ichlpc (to replace ichlpcib(4)) and acpiib (to let legacy devices attach there; I've only let npx(4) attach though for the sake of the test): pcib0 at pci0 dev 31 function 0: vendor 0x8086 product 0x27b9 (rev. 0x02) timecounter: Timecounter "pcib0/ichlpc" frequency 3579545 Hz quality 1000 pcib0/ichlpc: 24-bit timer pcib0/ichlpc: TCO (watchdog) timer configured. gpio5 at pcib0: 64 pins pcib0/acpiib: ACPI node SBRG npx1 at pcib0 (COPR, PNP0C04): io 0xf0-0xff irq 13 npx1: reported by CPUID; using exception 16 SIOR (PNP0C02) at pcib0 not configured RMSC (PNP0C02) at pcib0 not configured OMSC (PNP0C02) at pcib0 not configured A device flavour is essentially an incomplete device driver. That means it will never be active unless a driver has already attached to a device. But the main point is that a flavour can be created without the main driver being aware of it; additionally, a flavour gets its own device_t and thus can interact on its own with any subsystem that uses device_t, mostly pmf(9). (And, as you can see in the example, aprint_*_dev functions.) On the config(5) side, a device flavour is defined as something that attaches to an interface attribute. The reason for that is of course that there is no need for it to assume the name of the main driver to function properly. So, in my files.* I have defined the following: flavour acpiib at pci: acpinodebus filedev/acpi/acpiib.c acpiib flavour ichlpc at pci: acpipmtimer, sysmon_wdog, fwhichbus, hpetichbus, gpiobus filearch/x86/pci/ichlpc.c ichlpc And then in my kernel config file I added the following: flavours ichlpc, acpiib npx*at pcib? gpio* at gpiobus? (The last two lines are there only to explain the attachments in the example.) At run time, I am only going to describe what happens at attachment time, because I haven't done anything about detach yet. When a device is *found* (i.e., once its device_t has been created and linked) using the interface attribute "pci", the match functions of all flavours of the pci interface attribute are called, and for each that returns non-zero, a device_t object is created using the name "device/flavour" and add to the "parent" device_t's list of flavours. Then when what is really a sibling driver is attached, a call is made the the flavour's callback. In my proof-of-concept code I added a call right before the main driver is attached, and another one right after, because there might be situations where either is needed (and typically for a flavour that enumerates children, it might prefer doing it before the main driver gets a chance to do it). For reference, my current patch: http://taryn.cubidou.net/~cube/flavours.diff Again, it is a proof of concept; detaching is not handled, so the kernel will fail to reboot, and there is no locking whatsoever, so Bad Things could happen. There are other situations in which I think device flavours could bring clarity and also better modularisation. For instance, support for CPU features on x86 like EST or PowerNow, or even ACPI P-states could be done that way, and it is more module-friendly because it wouldn't require the main CPU driver to explicitely call those feature-drivers. I've been wondering about simply allowing more than one driver to attach to a device, and while this might be a lot simpler as far as config(1) and even autoconf(9) are concerned, it raises other issues, like how to deal with device_t's. One thing I'd like to get input on anyway is how to actually deal with pmf(9). I haven't looked at it at all yet, but I don't really expect miracles for my current patch. -- 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. pgpt1CgG4YB9c.pgp Description: PGP signature
Re: power management and pseudo-devices
On Sun, Jul 18, 2010 at 05:31:42PM -0700, Paul Goyette wrote: > On Mon, 19 Jul 2010, Quentin Garnier wrote: > > >>>Include "ioconf.h" I think. > >> > >>Tried that. It works for compiling the kernel. Unfortunately, > >>swwdog is included in rump, and there doesn't seem to be an ioconf.h > >>available for the librump build. > > > >Well, whatever. I don't think I want to look at that. > > :) Actually, I still think this is wrong. It might make librump compile and even link, that doesn't mean it will be usable if nothing ever creates that extern symbol. You'll have to check with pooka or explore the code, but there have to be some components of rump that have partial configuration files. After all, he created the "ioconf" directive for that purpose. -- 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. pgpm4e6nfBlwc.pgp Description: PGP signature
Re: power management and pseudo-devices
On Sun, Jul 18, 2010 at 04:52:58PM -0700, Paul Goyette wrote: [...] > >>+ > >>+extern struct cfdriver swwdog_cd; > > > >Include "ioconf.h" I think. > > Tried that. It works for compiling the kernel. Unfortunately, > swwdog is included in rump, and there doesn't seem to be an ioconf.h > available for the librump build. Well, whatever. I don't think I want to look at that. [...] > >Ok, so you should be aware here that you're changing the logic of that > >function, and you're only allowing for the creation of one swwdog(4). > > The limitation of only one swwdog(4) was deliberate, especially > since the original code had a "#define NSWWDOG 1" anyway! I missed that in the initial code. [...] > >While you're there, I guess you could make swwdog_reboot a sysctl node. > > Good point. Would this belong in the kern or machdep sysctl tree? I would set hw.swwdog.reboot. And I don't understand why you bother setting that up in swwdog_attach(), when we've just discussed there could only be one anyway (and assuming that there could be more than one, it seems to me that it would be plain overdesign to allow the setting to be set per-device, but that's just me). > -int swwdog_reboot = 0; /* set for panic instead of reboot */ > +bool swwdog_reboot = 0; /* set for panic instead of reboot */ If you change its type to bool, you might as well change the value to false. > Index: src/sys/dev/sysmon/files.sysmon > === > RCS file: /cvsroot/src/sys/dev/sysmon/files.sysmon,v > retrieving revision 1.11 > diff -u -p -r1.11 files.sysmon > --- src/sys/dev/sysmon/files.sysmon 30 Jan 2010 21:55:28 - 1.11 > +++ src/sys/dev/sysmon/files.sysmon 18 Jul 2010 23:21:06 - > @@ -18,5 +18,5 @@ filedev/sysmon/sysmon_wdog.csysmon_wdo > file dev/sysmon/sysmon.c sysmon_envsys | sysmon_wdog | > sysmon_power > > -defpseudo swwdog: sysmon_wdog > +defpseudodev swwdog: sysmon_wdog > filedev/sysmon/swwdog.cswwdog You know, I was looking at -5 sources, which have the needs-count flag there and therefore don't have the #define for NSWWDOG. Must be pooka's doing I guess; it's certainly better 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. pgp7q6VjWeClX.pgp Description: PGP signature
Re: power management and pseudo-devices
On Sun, Jul 18, 2010 at 12:35:31PM -0700, Paul Goyette wrote:
> (Resent, this time with attachment!)
>
> On Sun, 18 Jul 2010, Quentin Garnier wrote:
>
> >On Sun, Jul 18, 2010 at 07:14:57AM -0700, Paul Goyette wrote:
> >>Currently, pseudo-devices are silently attached to the device tree
> >>without giving the driver any access to the associated device_t
> >>structure. As a result, the pseudo-device driver is unable to
> >>access much of the pmf framework. In particular, the pseudo-device
> >>cannot register a suspend/resume/shutdown handler, nor can it
> >>register to receive pmf event notifications.
> >>
> >>It seems to me that it would be reasonably useful for pseudo-devices
> >>to be capabile of participating in pmf. One particular example I've
> >>run into recently is the swwdog pseudo-device. Other watchdog
> >>drivers can prevent a suspend if their timer is armed, but since
> >>swwdog is only a pseudo-device it cannot register a pmf handler.
> >
> >Convert it to a defpseudodev then.
>
> I've done this, and it works! Diffs attached. Any objections to
> committing them?
Not really objections, just a few comments.
> +struct swwdog_softc *sc_swwdog = NULL;
That can't possibly be needed (and, if it was, you'd have to mutexify it
wouldn't you?).
> +
> +extern struct cfdriver swwdog_cd;
Include "ioconf.h" I think.
> +swwdogattach(int n)
> {
> - int i;
> + int err;
> + cfdata_t cf;
> +
> + if (n > 1)
> + aprint_verbose("%s: ignoring count of %d\n",
> + swwdog_cd.cd_name, n);
> +
> + err = config_cfattach_attach(swwdog_cd.cd_name, &swwdog_ca);
> + if (err) {
> + aprint_error("%s: couldn't register cfattach: %d\n",
> + swwdog_cd.cd_name, err);
> + config_cfdriver_detach(&swwdog_cd);
> + return;
> + }
> +
> + cf = kmem_alloc(sizeof(struct cfdata), KM_NOSLEEP);
> + if (cf == NULL)
> + aprint_error("%s: couldn't allocate cfdata\n",
> + swwdog_cd.cd_name);
> + else {
> + cf->cf_name = swwdog_cd.cd_name;
> + cf->cf_atname = swwdog_cd.cd_name;
> + cf->cf_unit = 0;
> + cf->cf_fstate = FSTATE_STAR;
>
> - for (i = 0; i < NSWWDOG; i++) {
> - struct swwdog_softc *sc = &sc_wdog[i];
> + (void)config_attach_pseudo(cf);
Ok, so you should be aware here that you're changing the logic of that
function, and you're only allowing for the creation of one swwdog(4).
That feature of the old code--implemented with needs-count no less,
brrr--is highly debatable, and the manual page actually says it's
pointless.
So yeah, go ahead and kill it (you can keep the __unused on int count by
the way), but change the manual page.
Also, you don't have to allocate a struct cfdata, you can use a static
one (indepedently of the fact that you only use it once, by the way, all
the other pseudo-devices could be changed in that respect).
> +static int
> +swwdog_match(device_t parent, cfdata_t data, void *aux)
> +{
> + /* Match unless we already have a swwdog */
> + if (sc_swwdog == NULL)
> + return 1;
> +
> + return 0;
> +}
What could possibly trigger another config_attach_pseudo? I know that
config(9) is special, but not magic :-)
> + if (!pmf_device_register(self, NULL, NULL))
> + aprint_error_dev(self, "couldn't establish power "
> + "handler\n");
So what was your initial point about swwdog(4) and pmf(9), anyway?
While you're there, I guess you could make swwdog_reboot a sysctl node.
--
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.
pgpfGEuqltjV7.pgp
Description: PGP signature
Re: power management and pseudo-devices
On Sun, Jul 18, 2010 at 07:14:57AM -0700, Paul Goyette wrote: > Currently, pseudo-devices are silently attached to the device tree > without giving the driver any access to the associated device_t > structure. As a result, the pseudo-device driver is unable to > access much of the pmf framework. In particular, the pseudo-device > cannot register a suspend/resume/shutdown handler, nor can it > register to receive pmf event notifications. > > It seems to me that it would be reasonably useful for pseudo-devices > to be capabile of participating in pmf. One particular example I've > run into recently is the swwdog pseudo-device. Other watchdog > drivers can prevent a suspend if their timer is armed, but since > swwdog is only a pseudo-device it cannot register a pmf handler. Convert it to a defpseudodev then. -- 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. pgpSKG5AwFG9b.pgp Description: PGP signature
Re: remote kernel debugging over a network
On Sat, Jun 05, 2010 at 04:01:01PM -0400, der Mouse wrote: > > I have to make a decision about the protocol that will be used for > > remote kernel debugging. > > > My question is: Should I go with a custom protocol (+ a daemon that > > proxies to TCP), or should I go with TCP directly? > > My opinion, which is probably worth approximately what you paid for it: > custom protocol built directly atop Ethernet (ie, not IP-based). > > It seems to me that, for this application, the downsides of TCP > outweigh the upsides. It seems to me that something over IP nonetheless would be hugely convenient... -- 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. pgpDlmHh5lbsV.pgp Description: PGP signature
Re: Writing to multiple descriptors with one system call
On Wed, Mar 17, 2010 at 05:17:52PM +, Christos Zoulas wrote:
> In article <20100317131044.f26d5d99.cryintotheblue...@googlemail.com>,
> Sad Clouds wrote:
> >On Wed, 17 Mar 2010 12:50:51 +
> >Sad Clouds wrote:
> >
> >> Hi is there some undocumented system call that allows a user process
> >> to write to multiple descriptors in one go?
> >>
> >> What I'm looking for is a variation of writev() system call, e.g.:
> >>
> >> size_t write2v(int *d, int dcnt, const struct iovec *iov, int iovcnt);
> >>
> >> So the application builds an array of file descriptors and an array of
> >> iovec structures. It then calls write2v(), which goes through each
> >> file descriptor and writes buffers from iovec structures.
> >>
> >
> >On second thoughts, there needs to be a way to handle partial writes
> >
> >struct fdvec
> >{
> > int fd;
> > size_t nwritten;
> >};
> >
> >int write2v(
> > struct fdvec *fdv, int fdvcnt, const struct iovec *iov, int iovcnt);
> >
> >For each file descriptor, the function sets nwritten to the number of
> >bytes written. It returns 0 when all buffers in iovec structures were
> >written to all file descriptors, otherwise it returns >0 for each file
> >descriptor that was partially written.
>
> if you are going to build that, then it is probably easier to include
> all the info in the iovec:
I think you missed his point here, which is to write the *same* data to
all fds, and not to match a vector to a fd. It could work too, but then
instead of having 5000 struct fdvec and two struct iovec, you'd end up
with 1 struct iovec2.
--
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.
pgpesVotJdP0M.pgp
Description: PGP signature
Re: Writing to multiple descriptors with one system call
On Wed, Mar 17, 2010 at 01:10:44PM +, Sad Clouds wrote: > On Wed, 17 Mar 2010 12:50:51 + > Sad Clouds wrote: > > > Hi is there some undocumented system call that allows a user process > > to write to multiple descriptors in one go? Do you have a real world use for that? For instance, I wouldn't call a web server that sends the same data to all its clients *at the same time* realistic. > > What I'm looking for is a variation of writev() system call, e.g.: > > > > size_t write2v(int *d, int dcnt, const struct iovec *iov, int iovcnt); > > > > So the application builds an array of file descriptors and an array of > > iovec structures. It then calls write2v(), which goes through each > > file descriptor and writes buffers from iovec structures. > > > > On second thoughts, there needs to be a way to handle partial writes What do you do when you get EIO for the first fd, EPIPE for the second, EFBIG for the third, EINTR for the fourth and an undefined return status for the 4996 that follow? (I guess on a socket you might only get EIO, ENOSPC and EINTR, but you get the idea.) -- 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. pgpq4MJpssUYY.pgp Description: PGP signature
Re: config(5) break down
On Mon, Mar 15, 2010 at 11:50:09PM +0900, Masao Uebayashi wrote: [...] > Without looking them, I don't think any infrastructural (== config(1) You know, saying stuff like "without looking at [this]", or "i haven't read any of [that]", while honest, is not a very good way of leading a conversation. People might just think you're condescending. > itself) change helps. Why not fix source code rather than "improving" > config(1)? Because, like it or not, config(1) has to change, because autoconf(9) has to change, too. I know it's not part of your own agenda, but it's a fact. Now, you can choose to dismiss any opinion that includes a change in config(1), but you might also want to think about how changing config(1) could help you. If some people are going to change it anyway, why wouldn't you consider the benefits of adding changes that serve your agenda? -- 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. pgp4nfzzfgTl8.pgp Description: PGP signature
Re: (Semi-random) thoughts on device tree structure and devfs
On Thu, Mar 11, 2010 at 03:33:27PM +, Iain Hibbert wrote: [...] > and would also solve the (very slight) race condition, and moreover it > would not require malloc of cfdata. You can use a static cfdata_t, you know. The malloc'ing was a mistake made initially and carried upon since. -- 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. pgpYRkEMwfzxm.pgp Description: PGP signature
Re: (Semi-random) thoughts on device tree structure and devfs
On Tue, Mar 09, 2010 at 09:14:09PM +0100, Johnny Billquist wrote: > Quentin Garnier wrote: [...] > My answer only intended to show that the device enumeration isn't > random, depending on if you add/remove other devices, which is what > Masao was claiming. Your answer only says that device enumeration is deterministic. Nobody said that it wasn't. I know autoconf(9) hasn't aged very well, but it's not that bad. Yet. -- 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. pgpvh4h9DeJ17.pgp Description: PGP signature
Re: (Semi-random) thoughts on device tree structure and devfs
On Tue, Mar 09, 2010 at 08:51:48PM +0100, Johnny Billquist wrote: > "More or less", because I don't have all the details. If you were to > post the dmesg from your booting, I could give you the exact thing. > > Are you sure your USB disk shows up as sd? Looking at the config > file, I would have thought it would match wd. > > If it is wd, then the config should have something along these lines: > > wd0 at umass0 > umass0 at uhub0 port 0 configuration 0 interface 0 > uhub0 at usb0 > usb0 at uhci0 > uhci0 at pci1 dev 1 function 0 > pci1 at ppb0 bus 0 > ppb0 at pci0 dev 0 function 0 > pci0 at mainbus 0 bus 0 > > > Obviously I've thrown in a bunch of "0" here, where there probably > should be something else, as well as a "1", since you have two pci > buses involved already at this point. > That's the "more or less" part. Now, if you don't understand the > concept based on this, then I don't think putting correct numbers in > here is going to help much more either. The basic idea though, is > that this will always cause the same disk to be wd0, and no other > disk will ever become that. No matter what hardware you add, or > where. What you really don't seem to understand is that this answers only half of the contract. Put the drive in another USB port and it doesn't show up as wd0. The idea was that only that disk would show up as wd0, and would always show up as wd0. (Incidentally, w...@umass is very rare. I think it was only some old Archos.) -- 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. pgpEzyjexwHhw.pgp Description: PGP signature
Re: config(5) break down
On Mon, Mar 08, 2010 at 04:43:17PM +, Eduardo Horvath wrote:
> On Fri, 5 Mar 2010, Masao Uebayashi wrote:
>
> > I've found that the difficulty of understanding config(5) is due to its
> > flexibility; it can do one thing in many ways. You can define a collection
> > of sources with define, defflag, device, defpseudo{,dev}, devfs. OTOH you
> > can only write dependency on attributes (define). Another example is, you
> > can write interface with define, device, defpseudodev.
> >
> > I'd propose to make a rule to simplify things (at the cost of a little
> > redundancy of config(5) files).
>
> Allright. I have to ask:
>
> If the plan is to go to a dynamically probed system with loadable modules,
> why keep config around at all? It's only useful for custom kernels. Why
> is it useful to give config a facelift instead of doing away with it
> entirely?
config(5) files carry information on what source file to build, under
what conditions as well as information about drivers and relationships
between devices. Why would you do away with it entirely? All that
information will have to be stored somewhere anyway.
--
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.
pgph9qv88iLea.pgp
Description: PGP signature
Re: (Semi-random) thoughts on device tree structure and devfs
On Sun, Mar 07, 2010 at 10:31:52PM -0600, Eric Haszlakiewicz wrote: > On Sun, Mar 07, 2010 at 08:50:03PM +0000, Quentin Garnier wrote: > > On Sun, Mar 07, 2010 at 06:43:49PM +0900, Masao Uebayashi wrote: [...] > > > - Intuitivity > > > Behavior should be simple enough for users to guess without looking into > > > code. > > > > What kind of user do you talk about here? If it's the end user, then > > this is wrong. All that you mention should be irrelevant to them. > > Careful here: does "end user" mean grandma clicking though KDE, or an admin > figuring out why one disk of his raid component disappeared? More precise > definitions and terminology might be helpful. Well, even if the admin gives proper names to all the disks and such, yes, there is one moment when they'll be faced with details of the device tree. But to me it's a brief part of the setup, not really of the use. The click-through user has their administrative tasks proxied by things like hald(8), but I expect said proxy to see as little gory details as a human admin as well. [...] > > > 1) Introducing devfs > ...snip... > > Beside, imagine you move said hard drive from one port to the other (or > > on to another, say, faster controller); the ultimate idea of devfs is > > that the device node for the hard drive doesn't change. > > > > Not that full, explicit device paths aren't something useful to expose > > one way or another to the userland. It's just not what devfs is about, > > so you should revise your vocabulary here. > > I thought this was *one* of the things that devfs was supposed to do. The > two features being: >1) provide a way to see detailed information about how devices are laid out > and, the one relevant for this discussion >2) provide stable names for devices that don't change if they happen to be > laid out differently today vs. yesterday. > > with #2 possibly provided by a userland script that parses the structure > provided by #1, plus whatever additional information it needs, and creates > symlinks (or otherwise causes device nodes to appear in the right paths) > #2 == simplicity, #1 == transparency and (low level) control > > Perhaps I'm muddling the base feature requirements with various ideas for > implementations? There's nothing complicated about what devfs is for: having all the relevant device nodes in /dev, and only those. Anything else is an implementation detail. Neither #1 or #2 are part of the immediate goal of devfs. I don't see why #1 should be a part of a devfs implementation, and #2 is certainly something nice to have, but it goes beyond the initial intent of a devfs. -- 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. pgp9lD9WlH6UA.pgp Description: PGP signature
Re: (Semi-random) thoughts on device tree structure and devfs
On Mon, Mar 08, 2010 at 01:56:28AM +0100, Johnny Billquist wrote: > Is it just me who find this whole ide ironic? I'm not sure you grasp the whole thing here. > Have everyone forgotten how to set up their own kernel? Is everyone > now booting GENERIC? (Or just making a copy of GENERIC, with a few > patches without understanding what they are editing?) How exactly does hard-wiring a kernel helps with some of the issues described here? Say you have two USB drives, and plug them in a different order in different ports (which defeats all config(5) trickery). > The whole point being that if you boot a kernel, in which you have > configured the whole system to connect anything anywhere, you should > not be surprised if the device enumeration might seem random. Yes, it is random, and should be considered as such. That doesn't mean, however, that it is impossible to somehow locate device in a constant way regardless of how they attached. I know that poeple have been using raidframe to do just that for a very long time. > The asterisks and question marks means exactly that. If you want > predictable matching that stays the same at every boot, no matter > what hardware you put on the system, you write explicit lines in the > config instead. There is a lot to be gained from providing a useful binary distribution of NetBSD. That includes a kernel that people don't have to play with in order to make it useful. Grumpy old farts will always compile their own kernel and do their own thing, but fortunately I don't think it is a goal for anybody in the NetBSD community to be useful only to grumpy old farts. [...] > (Do I need to say that I agree with Quentin?) Are you still positive about that? I am certainly not advocating the status quo. -- 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. pgpDuhnnpYKEA.pgp Description: PGP signature
Re: (Semi-random) thoughts on device tree structure and devfs
On Sun, Mar 07, 2010 at 06:43:49PM +0900, Masao Uebayashi wrote: [...] > a) Device enumeration is unstable / unpredictable > > dk(4) is a pseudo device, and its instances are numbered in the order it's > created. This is fine when you manually / explicitly add wedges(4) by using > "dkctl addwedge". This is not fine, if I have a gpt(4) disk label which has > ordered partitions. I expect disks to be created in the order I write in > the gpt(4) disk label. It's annoying the numbering changes when I add a new > disk. Same for raidframe(4). You're barking up the wrong tree. What's annoying is not that the numbering changes. It is that the numbering is relevant to the use of the device. I expect dk(4) devices to be given names (be it real names or GUIDs), and I expect to be able to use that whenever I currently have to use a string of the form "dkN". [...] > - Intuitivity > > Behavior should be simple enough for users to guess without looking into code. What kind of user do you talk about here? If it's the end user, then this is wrong. All that you mention should be irrelevant to them. > - Predictability / stability > > Device numbers don't change surprisingly. When you plug device A and B in > slot 1 and 2, they should be shown in that order. When you add disk B @ slot > 2, the number of disk A @ slot 1 must not change. Wrong. Device numbers should be irrelevant to anything but operations on device_t objects. > - Simplicity, clarity, consistency > > Common code is concentrated in single place. Each driver implements only its > hardware accessors. No scattered ioctl handlings. You forgot world peace. > 1) Introducing devfs > > devfs is a pseudo filesystem which shows device topology in a mount point. This is not what devfs is. > There's (unfinished) branch mjf-devfs. devfs helps to identify devices > uniquely. wd0 on my DELL OptiPlex 745 looks like: > > /dev/mainbus/pci0/ppb0/piixide0/atabus0/wd0 This has nothing to do with what devfs is about. If your idea of devfs is that the user should know the whole device path to access a hard drive, you have strange ideas about simplicity. Beside, imagine you move said hard drive from one port to the other (or on to another, say, faster controller); the ultimate idea of devfs is that the device node for the hard drive doesn't change. Not that full, explicit device paths aren't something useful to expose one way or another to the userland. It's just not what devfs is about, so you should revise your vocabulary here. > 2) Natural device numbering > > Device number in devfs is enumerated locally in the attachment. Numbers are > *naturally* assigned; should match physical bus/slot numbers so that users > can make sure which is which. This is important especially for block devices. > Think when you plug a USB floppy and newfs it. Again, users shouldn't have to care about device numbering. With your idea of numbering, the way to access a device should change depending on which USB port I put my usb key drive in? I fail to see how this is better than what we have now. [...] > 3) "Functional" device instances abstraction [...] > This also helps users to understand how its internal works. Users basically > accesses the device via audio(4) interface. audio(4) is responsible to > interact with real hardware drivers. Both control and data are transfered > via audio(4). It's also easily guessed if user forcibly control real device > (azalia(4)), audio(4) would be *surprised*, and some inconsistency will be > expected to happen. > > wscons(4)/tty(4) could be abstracted like: > > /dev/mainbus0/.../pci0/vga0/display0/screen0/vt100emul0/termios0/tty0 > > This might look redundant, but each device instance's *responsibility* is > very clear. tty(4) is *the* device you interact when you use it as a tty. > Pretty much straightforward. When you send a tty ioctl, it goes to tty(4), > which may be delivered to upper layers. To add a new screen, it's obvious > that the device we should ask to is display(4). We can guess how control/data > is delivered. We can also guess forcibly deleting a screen causes its child > devices problems, because topology is visible. > > wscons(4) without emulation would look like: > > /dev/mainbus0/.../pci0/vga0/display0/screen1 > > We don't need a detailed manual page how screen0 / screen1 are interfaced, > because it's obvious. Are you really just discovering that wscons needs a lot of love? It's old news. The problem is that nobody wants to deal with that mess and the ensuing binary compatibility nightmare. [...] > P.S. I've read 0 line of devfs code yet. Really? It seems to me that
Re: (Semi-random) thoughts on device tree structure and devfs
On Sun, Mar 07, 2010 at 06:16:18PM +0200, Jukka Ruohonen wrote: > On Sun, Mar 07, 2010 at 06:43:49PM +0900, Masao Uebayashi wrote: > > Where component devices are symlinks to the real instances > > > > /dev/pseudobus0/raid0/component0 > > -> /dev/mainbus/pci0/ppb0/piixide0/atabus0/wd1/disk0/diskpart0 > > I already pointed this out on port-i386@, but theoretically this sounds like > a good thing for the ACPI side of things where "pseudo" (ACPI) devices need > to be matched with "real" devices. > > As an example: one thing that holds back the ACPI CPU code I am working on > is that I need to be sure that e.g. cpu3 that attaches to acpi0 is the same > cpu3 that has attached to mainbus0. So: Well, the answer to that is simple: there should only be one device. Anything design that doesn't produce that result can go to thrown out the window without further delay. -- 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. pgpOsp6S0yhlM.pgp Description: PGP signature
Re: pseudoify cgd
On Fri, Jan 01, 2010 at 03:08:45PM +0100, Jan Danielsson wrote: > Hello, > >Here's the latest patch. I cleaned out numcgd, fixed conf/files, > moved disk_destroy() so it's more symmetric with disk_init(). Comments? > Is it commit worthy? Definitely; one of the worthy side effect is the removal of a static limit over the number of cgd(4) devices. -- 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. pgp7hdvtgYyMu.pgp Description: PGP signature
Re: pseudoify cgd
On Fri, Jan 01, 2010 at 10:29:00AM +, Iain Hibbert wrote: > On Thu, 31 Dec 2009, Quentin Garnier wrote: > > > - I looked at the code the other day, and I don't see any reason to > > allocate a cfdata_t for each device_t. I'm fairly certain you can > > just use a static one common to all instances. I know all the other > > drivers do that, but that's just people copy-pasting code without > > really understanding it (I'm just as guilty as the others). > > I looked at that once also and came to the conclusion that while it would > probably work fine, it was better to allocate because the cfdata is not > specified as const in any documentation and indeed, config_attach_pseudo() > does modify it in certain cases which I didn't necessarily understand.. Of course it modifies it. If it's not a star instance, it has to keep track that it was found. If you look at the code, you'll see that a cfdata_t is only ever modified if it is not a star instance. How complex it might look, it's easy to understand: a cfdata_t is a line in the kernel configuration file, e.g. "driver* at bus? loc ? flags 0". Having said that, you might question the utility of a static instance for a pseudo-device, but maybe someone will have a use for that. -- 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. pgpzAPR2t9nFA.pgp Description: PGP signature
Re: pseudoify cgd
On Thu, Dec 31, 2009 at 11:35:59PM +0100, Jan Danielsson wrote: > Hello, > >The attached diff is essentially a diff by David Young, which I > tweaked slightly (it wouldn't apply entirely against a more current > source tree). > >The motivation for this was because I needed access to the cgd > device's device_t. > >Does it look ok? It does. Two things, though: - numcgd is no longer necessary. You should remove all references to it, and when you commit it, you can remove all the numbers in the kernel config files for the "pseudo-device cgd" line. - I looked at the code the other day, and I don't see any reason to allocate a cfdata_t for each device_t. I'm fairly certain you can just use a static one common to all instances. I know all the other drivers do that, but that's just people copy-pasting code without really understanding it (I'm just as guilty as the others). -- 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. pgpBP7YWLGdo5.pgp Description: PGP signature
