Hi Heinrich, On Wed, 23 Jan 2019 at 10:05, Heinrich Schuchardt <xypron.g...@gmx.de> wrote: > > On 1/22/19 8:39 PM, Simon Glass wrote: > > Hi Alex, > > > > On Tue, 22 Jan 2019 at 22:08, Alexander Graf <ag...@suse.de> wrote: > >> > >> > >> > >> On 22.01.19 09:29, AKASHI Takahiro wrote: > >>> Alex, Simon, > >>> > >>> Apologies for my slow response on this matter, > >>> > >>> On Fri, Jan 11, 2019 at 08:57:05AM +0100, Alexander Graf wrote: > >>>> > >>>> > >>>> On 11.01.19 05:29, AKASHI Takahiro wrote: > >>>>> Alex, Heinrich and Simon, > >>>>> > >>>>> Thank you for your comments, they are all valuable but also make me > >>>>> confused as different people have different requirements :) > >>>>> I'm not sure that all of us share the same *ultimate* goal here. > >>>> > >>>> The shared ultimate goal is to "merge" (as Simon put it) dm and efi > >>>> objects. > >>> > >>> I don't still understand what "merge" means very well. > >> > >> It basically means that "struct efi_object" moves into "struct udevice". > >> Every udevice instance of type UCLASS_BLK would expose the block and > >> device_path protocols. > >> > >> This will be a slightly bigger rework, but eventually allows us to > >> basically get rid of efi_init_obj_list() I think. > > > > I envisaged something like: > > > > - EFI objects have their own UCLASS_EFI uclass > > - DM uclasses which support EFI would create a child EFI device (e.g. > > a UCLASS_EFI child of each UCLASS_BLK device) > > - EFI-uclass devices would thus be bound as needed > > - Probing an EFI device would causes its parents to be probed > > - We can use all the existing DM hooks (probe, remove, parent/child > > data, operations), to implement EFI things > > > > I'm assuming that a small percentage of devices would have EFI > > children, so that this is more efficient than trying to merge the data > > structures. It also allows EFI to maintain some separate from the core > > DM code. > > Dear Simon, > > thanks to your suggestions. > > I am not yet convinced that an UCLASS_EFI child device will be helpful. > It is not an EFI object. > > A DM uclass is the equivalent to an EFI driver, i.e. a handle with the > EFI_DRIVER_BINDING_PROTOCOL installed on it [1]. So the natural thing > for a uclass supporting EFI would be to provide such a handle. > > For the actual devices we also need handles.
Yes but I understand why this is problematic? > > In the EFI world partitions are devices. How does this fit into your > picture? Perhaps we could consider adding a UCLASS_PARTITION? The rework of the FS layer may not be too much - at least once we drop the non-BLK code (as you say at [1]). > > [1] https://lists.denx.de/pipermail/u-boot/2019-January/354359.html > [RFC] Device model for block devices - integration with EFI subsystem > > Best regards > > Heinrich > > > > >> > >>> > >>>> But we have this annoying interim state where we would lose a few boards > >>>> because they haven't been converted to DM. That's what keeps us from it. > >>>> > >>>> I think what this discussion boils down to is that someone needs to > >>>> start prototyping the DM/EFI integration. Start off with a simple > >>>> subsystem, like BLK. > >>> > >>> Even in the current implementation, > >>> * UEFI disk is implemented using UCLASS_BLK devices > >>> (We can ignore !CONFIG_BLK case now as we have agreed.) > >>> * UEFI-specific block device can be seen as UCLASS_BLK/IF_TYPE_EFI > >>> > >>> So how essentially different is the *ultimate* goal from the current form > >>> regarding block devices? > >> > >> The ultimate goal is that efi_disk_register() and efi_obj_list disappear. > >> > >> Functionality wise we should be 100% identical to today, so all test > >> cases would still apply the same way as they do now. This is purely > >> internal rework, nothing visible to UEFI payloads. > > > > Yes. > > > >> > >>> In order to identify UEFI disks with u-boot devices transparently, we will > >>> have to have some sort of *hook* (or hotplug in Alex's language?), either > >>> in create_block_devices or bind/probe? I don't know, but Simon seems > >>> to be in denial about this idea. > >> > >> Well, if a udevice *is* an efi device, we no longer need hooks. The > >> object list would simply change. > >> > >> We may still need to have event notifications at that stage, but that's > >> a different story. > > > > Yes, it's something that I think will need to be added to DM. I > > haven't got to this as I have not run into an important use case yet. > > Maybe something like: > > > > Controlled by CONFIG_EVENT > > > > - int dev_ev_register(struct udevice *dev, enum event_t type, > > event_handler_func_t handler, void *userdata) > > > > which calls handler(struct udevice *dev, void *userdata) when an event is > > fired > > > > - int dev_ev_unregister() to unregister > > > > - int dev_ev_send(struct udevice *dev, enum struct event_info *info) > > > > which sends events to registered listeners. > > > > struct event_info { > > enum event_t type; > > union { > > struct ev_data_probed probed; > > struct ev_data_removed removed; > > ... > > } d; > > }; > > > >> > >> As transitioning period, we could probably implement 2 efi object roots: > >> efi_obj_list as well as the udevice based one. Every piece of code that > >> iterates through devices then just iterates over both. That way we > >> should be able to slowly move devices from the old object model to the > >> new one. > > > > Will the uclass I mentioned above you can iterate through UCLASS_EFI > > and thus you have a list of EFI devices. > > > > [...] > > > > Regards, > > Simon > > > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
