Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
Daniel Walker wrote: > > But all the rest is arbitrary and could be part of common shared > > profiles or the like in defconfig format. > > I'm sure most people will want to have a config isolated to their > specific device. That to me seems reasonable because everyone wants the > smallest possible kernel they can get for their given device. Indeed, but people who want the smallest possible kernel for their specific device _in a particular use context_ tend to want: - To disable support for parts of the device they aren't using. For example, an SoC with integrated ethernet that isn't actually wired up on their board, or where they're using an external ethernet chip instead for some reason. - To choose what's modular and what isn't, even for integrated parts. For example to control the bootup sequence, they might want to delay integrated USB and IDE initialisation, which is done by making those modular and loading them after bringing up a splash screen earlier in the boot scripts. So there is still a need to be able to override the drivers and settings, but it's still incredibly useful to have defaults which describe the SoC or board accurately. -- Jamie ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
Mike Rapoport wrote: > >Which of course raises the question: How does the Linux community view > >such SoC vendors? Are they embraced and eagerly supported, or (either > >openly or secretly) viewed as a nuisance? How does the widespread > >objection to something that such vendors "would make extensive use of" > >mesh with that view? > > I cannot tell for the entire Linux community, but from what I know, such > vendors are not much welcomed in the community. As far as I can tell, many such vendors don't have much interest in contributing to the Linux community either. They use Linux code, glue in their black-box binary modules and/or HALs, and engage poorly with the community. It is not just end-product makers, but upstream component, board and SDK manufacturers too. -- Jamie ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
Grant Likely wrote: > > Like initrd, some people will find they need to compile it in to the > > kernel image to fit some bootloader they can't change, or daren't risk > > changing in already rolled out devices that they want to update to a > > DT-using kernel. > > Yes, I fully expect that. Fortunately the situation is better than it > was with powerpc. Since the machine id is being retained, a > DT-enabled kernel can continue to support non-DT systems. There will > not be a flag day to cut everything over to a new boot interface. That's excellent, thank you. I was a bit unsure about how that was going. -- Jamie ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
Nicolas Pitre wrote: > On Mon, 14 Jun 2010, David Gibson wrote: > > > On Sun, Jun 13, 2010 at 11:02:15PM -0600, Grant Likely wrote: > > [sni] > > > > That's sort of a self-fulfilling prophecy. If the OS doesn't trust the > > > > firmware, there is no pressure for the firmware to "get it right". > > > > > > Firmware will not get it right. Period. There will always be > > > something wrong. It is never right on PCs. It will never be right on > > > the other architectures. > > > > Yes, yes, yes. And there is a great deal of empirical evidence to > > back that assertion. > > > > > That goes for OSes too, but upgrading an OS > > > isn't as risky as upgrading firmware. That isn't to say that it can't > > > be close, but every firmware feature that the OS depends on is a > > > feature that could force a risky firmware upgrade when the bug in it > > > is discovered. > > > > Indeed. In fact, the general rule of thumb is really "put as much as > > possible into the most easily replaced layer of the stack". This is, > > incidentally, why I've always been dubious about simple firmwares > > supplying a flattened device tree rather than including the device > > tree template in the kernel, cuboot style. > > The biggest advantage, IMHO, for adding DT to ARM, is actually to > decouple the hardware config information and the kernel. If in the end > the DT has to be shipped in the kernel then we're losing all this > advantage over the current state of things on ARM which still works > pretty well otherwise. > > In the best case, the simple firmware simply has to retrieve the > flattened device tree from flash, and pass it to the kernel just like > some anonymous blob. And the simple firmware only needs to provide a > way for that DT blob to be updatable, like through an upload of a > replacement blob that was prepared offline. Just like a ramdisk image > or the like. > > That doesn't need to be fancier than that, and the goal of having the DT > data tied to the hardware instead of the kernel is achieved. Imho that puts the DT in a similar category as initrd/initramfs, from the bootloader's point of view. It's another blob whose address is passed to the kernel, just like initrd. Some bootloaders can't update blobs independently for technical reasons, or to be minimal. A device I'm using does kernel updates by updating the whole romfs boot image, which contains the kernel and other auxiliary blobs used for booting (splash screen, early irq handlers etc.) as well as the root filesystem. It is done that way to pack everything together in the small flash, and because the NOR flash eraseblocks are too large relative to the whole flash size to use separate partitions for kernel, boot filesystem and other blobs for booting. Dedicating a 64kiB eraseblock out of 2MB just for a small DT would be quite wasteful. Dedicating two to make it powerfail-safe would be even worse. So requiring that a bootloader can update the DT _independently_ of everything else is a bit much for some devices. But requiring that it's generally treated like other separate blob, i.e. in a similar way to initrd, and the kernel image itself, seems not unreasonable. Like initrd, some people will find they need to compile it in to the kernel image to fit some bootloader they can't change, or daren't risk changing in already rolled out devices that they want to update to a DT-using kernel. I won't be surprised if I see some vendor SDK containing a kernel patch to early-parse the bootloader-supplied ROMFS image to extract "devicetree.bin.gz" at some point :-) We can discourage that sort of thing (but not prevent it) by ensuring the open source bootloaders support a DT blob as easily as possible. -- Jamie ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
Russell King - ARM Linux wrote: > On Mon, Jun 14, 2010 at 07:36:10PM +1000, Benjamin Herrenschmidt wrote: > > However, there's a lot of room for abuse here and I'm worried that if it > > becomes widespread, we'll start seeing vendors use that as a way to do > > some kind of HAL and hide various platform methods in there (clock > > control, nvram, etc...). > > This is what I'm worried about too. > > As I said in my first reply in this thread, calling out from the kernel > will kill performance due to the time taken to shut down the caches and > MMU, which can only be done safely with all exceptions turned off. Some applications use ARM (or other "embedded"-ish CPU) as opposed to x86 PCs, to get predictable and reasonable interrupt latency. x86 PCs sometimes have unpredictable interrupt latency due to those mystery interrupts that the BIOS handles and the OS can't see or block. It's a different cause, but let's not duplicate the symptom where it isn't wanted. Even if opaque firmware callouts were fast, it would be an issue with real-time kernels if they couldn't depend on that as an auditable fact. -- Jamie ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Qemu-devel] Re: Extending virtio_console to support multiple ports
Alan Cox wrote: > > - Then, are we certain that there's no case where the tty layer will > > call us with some lock held or in an atomic context ? To be honest, > > I've totally lost track of the locking rules in tty land lately so it > > might well be ok, but something to verify. > > Some of the less well behaved line disciplines do this and always have > done. I had a backtrace in my kernel log recently which looked like that, while doing PPP over Bluetooth RFCOMM. Resulted in AppArmor complaining that it's hook was being called in irq context. -- Jamie ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
