On 4 February 2013 20:51, Paolo Bonzini <pbonz...@redhat.com> wrote: > Il 04/02/2013 21:33, Peter Maydell ha scritto: >>> The $FOO device models should all be in hw/$FOO. But there are some >>> parts that do not fit in a category >> >> Surely this is what hw/misc is for? > > It's mostly interrupt/GPIO/DMA/memory/cache controllers. I placed some > of them are in hw/misc because they are in common-obj-y, but I don't > like the idea of hw/misc very much. hw/misc is really for the one-offs > such as the tmp105.c temperature controller. > > If you prefer with creating a bunch of hw/ subdirectories like hw/pic, > hw/gpio, hw/dma I can certainly move more stuff out of hw/$TARGET. As > long as there is consensus, it's fine. But I wanted to avoid > proliferation of hw/$FOO directories having only 5-10 files.
I don't care if devices go in hw/misc or hw/extremely-fine-grained-category as long as they don't go in hw/$TARGET :-) > The final submission may not have an hw/misc at all, the odd device like > tmp105.c can go in hw/i2c. > >> (Also a hw/machines might be a good idea.) > > I don't like it very much because it's not clear which targets are used > for which machines. I want to move away from the hw/arm/../foo.o hack > that is used now. Why should you care which machine models happen to have particular CPUs? In future we may even have machine models which have two CPUs of different architectures... >>> or are always target-specific, and >>> hw/$TARGET has them. >>> >>> Also, the kernel similarly has arch/$TARGET and drivers/$FOO. >> >> Yes, and the ARM kernel maintainers have just spent quite a lot >> of effort in cleaning things up to kick all the drivers out >> of arch/$TARGET and into drivers/$FOO where they belong. >> I'd rather we didn't get into that mess in the first place :-) > > Yes, and in fact I'm moving a lot of ARM devices away from hw/arm's > Makefile.objs to other directories (net/ for NICs, char/ for UARTs > etc.), and configuring them via default-configs/arm-softmmu.mak. > > But Linux still has a bunch of board-specific drivers in arch/arm/mach-* > that won't be moved to drivers/, and that's roughly what I left in > hw/$TARGET. (This is a bit of a tangent, but As I understand it, if it's really a driver it should be moving. >From https://lwn.net/Articles/443510/: "There will of course need to be at least some ARM-specific code [in arch/arm], but the end goal is for that code to be limited to ARM core architecture code and ARM SoC core architecture code. Furthermore, the ARM SoC core architecture code should consist primarily of small plugins for core-Linux-kernel frameworks". arch/arm64 won't have mach-* subdirs at all, we are stomping on that before it starts :-) By analogy with this, anything we have which is a self-contained device should definitely not be in hw/$TARGET. Small bits of code like arm_boot.c, OK (and perhaps machine models, though I'm dubious there because I'd like to see us moving to a framework where machine models are just another kind of device). But if it's really a device and we've been able to model it as a qdev device then it shouldn't be in hw/$TARGET. > (Note: some boards still have devices in hw/arm after these patches, > e.g. musicpal has a NIC and LCD controller. Those could indeed be > refactored to other directories. However, this series is not splitting > files, only moving them. The purpose is to get out of the local optimum > we're stuck in). I could live with a rule that says "no devices in hw/$TARGET unless they're there for legacy reasons because they share a source file with a machine model" [and ideally eventually pull any self-contained devices out of those files]. That's a nice clear line for reviewing new patches. Why, for example, is arm_gic.c moved to hw/arm but hw/heathrow_pic.c moved to hw/misc rather than hw/ppc ? -- PMM
