> Am 28.01.2019 um 09:56 schrieb AKASHI Takahiro <takahiro.aka...@linaro.org>: > >> On Fri, Jan 25, 2019 at 10:31:20AM +0100, Alexander Graf wrote: >> >> >>> On 25.01.19 10:18, AKASHI Takahiro wrote: >>>> On Fri, Jan 25, 2019 at 09:52:31AM +0100, Alexander Graf wrote: >>>> >>>> >>>>> On 25.01.19 09:27, AKASHI Takahiro wrote: >>>>> Alex, >>>>> >>>>>> On Wed, Jan 23, 2019 at 10:51:29AM +0100, Alexander Graf wrote: >>>>>>> On 01/22/2019 08: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 >>>>>> >>>>>> ... and then we need to create our own sub object model around the >>>>>> UCLASS_EFI devices again. I' not convinced that's a great idea yet :). I >>>>>> really see little reason not to just expose every dm device as EFI >>>>>> handle. >>>>>> Things would plug in quite naturally I think. >>>>> >>>>> You said that the ultimate goal is to remove all efi_object data. >>>>> Do you think that all the existing efi_object can be mapped to >>>>> one of existing u-boot uclass devices? >>>>> >>>>> If so, what would be an real entity of a UEFI handle? >>>>> struct udevice *? >>>>> >>>>> But Simon seems not to agree to adding any UEFI-specific members >>>>> in struct udevice. >>>> >>>> I think we'll have to experiment with both approaches. I personally >>>> would like to have struct udevice * be the UEFI handle, yes. >>>> >>>>> >>>>>> But either way, someone would need to sit down and prototype things to be >>>>>> sure. >>>>>> >>>>> >>>>> The most simplest prototype would include >>>>> * event mechanism (just registration and execution of hook/handler) >>>>> event: udevice creation (and deletion) >>>>> * efi_disk hook for udevice(UCLASS_BLK) creation >>>>> * modified block device's enumeration code, say, scsi_scan(), >>>>> to add an event hook at udevice creation >>>>> * removing efi_disk_register() from efi_init_obj_list() >>>>> * Optionally(?) UCLASS_PARTITION >>>>> (Partition udevices would be created in part_init().) >>>> >>>> Almost. >>>> >>>> The simplest prototype would be to add a struct efi_object into struct >>>> udevice. Then whenever we're looping over efi_obj_list in the code, we >>>> additionally loop over all udevices to find the handle. >>> >>> Ah, yes. You're going further :) >>> >>>> Then, we could slowly give the uclasses explicit knowledge of uefi >>>> protocols. So most of the logic of efi_disk_register() would move into >>>> (or get called by) drivers/block/blk-uclass.c:blk_create_device(). >>> >>> Via event? Otherwise, we cannot decouple u-boot and UEFI world. >> >> For a prototype, just make it explicit and see how far that gets us. >> >>>> Instead of creating diskobj and adding calling efi_add_handle(), we >>>> could then just use existing data structure from the udevice (and its >>>> platdata). >>> >>> I don't have good confidence that we can remove struct efi_disk_obj, >>> at least, for the time being as some of its members are quite UEFI-specific. >> >> Maybe we can move them into struct blk_desc? It's a matter of >> experimenting I guess. >> >>> >>>> >>>> Does this make sense? Less events, more implicity :). >>> >>> I'll go for it. >> >> Thanks a lot :). Feel free to pick an easier target for starters too if >> you prefer. > > Prototyping is done :) > Since it was so easy and simple, now I'm thinking of implementing > UCLASS_PARTITION. But it is not so straightforward as I expected, > and it won't bring us lots of advantages. > (I think that blk_desc should also support a partition in its own.) > > Once it gets working, may I send out a patch?
Feel free to even just send a patch of what you have now as RFC, so that we can see if this looks like the right direction. Let's make use of our time zone differences :). Alex _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
