> The intended use case for buffer registration is: > > - a group of processes attach a shmem segment > - one process registers the buffers in the shmem segment and shares it > - other processes attach that registration > > For this case, it seems that there is really no need to wait for the attached processes to get rid of the their references since the shmem segment (and thus the registered buffers) will persist anyway until the last attached process goes away. So the last unregister could quiesce all references and get rid of the shared buf_data. > > I'm not sure how useful the non-shmem use case would be anyway. > > Would it makes sense to restrict the scope of this feature? I have to say I like that generic resources thing, makes it easier to extend in the future. e.g. pre-allocating dma mappings, structs like bios, etc. I didn't think it through properly but it also looks that with refnodes it would be much easier to do sharing in the end, if not possible vs impossible. -- Pavel Begunkov
