The quantum cache is disabled, there is no uma.
Intent is to use this for resource allocation in bhyve(8), for start. Addition of -luvmem to bhyve linking was done to test changes to share/mk.
Differential D27220
libuvmem: usermode port of vmem(9) kib on Nov 14 2020, 10:13 PM. Authored by Tags None Referenced Files
Details
The quantum cache is disabled, there is no uma. Intent is to use this for resource allocation in bhyve(8), for start. Addition of -luvmem to bhyve linking was done to test changes to share/mk.
Diff Detail
Event TimelineThere are a very large number of changes, so older changes are hidden. Show Older Changes Comment Actions Seems ok to me, just nitpicking.
Comment Actions Hi, is there a concrete reason why this revision never landed or has it just slipped through the cracks? I would really like to use libuvmem for one of my ongoing bhyve projects and would like to see this land, let me know if there a way I could help with that. Comment Actions The intent of the libuvmem port was to use vmem allocator for bhyve to handle physical address space. That stalled, and I do not see a reason to add unused library to base. Meantime I rebased the branch. Comment Actions Remove undefined symbols from the version script. The library should be buildable, at least. Comment Actions Use standard way to reference libc src dir.
Comment Actions Is there a revision with the stalled patches somewhere? I'd be interested in taking a look.
That would be amazing, thank you! Comment Actions I suspect none survived, since I only found this libuvmem diff itself on that branch.
Yes this is exactly the place where libuvmem should fit perfectly. Comment Actions IMO it is generally useful API. Also, I do provide symbol versioning, which does not make sense for a private library: the intent is to keep stable interfaces. Comment Actions Well, now the kernel's internal interface must be kept stable as well. I don't object, but I'm worried it'll be easy for someone modifying vmem to forget about this. If the library is public, it should get a man page IMO, even if it just points at vmem(9). Comment Actions Yes, I noted the same when parts of msdosfs were used in makefs (AFAIR). But there it is much simpler interface, and if the interface for kernel or userspace starts drifting, the code can be easily forked to the residual part. Comment Actions My point is that no automation (e.g., tests) will catch this drift until after it is a problem for some hypothetical users. If makefs -t msdos is broken somehow, we will notice fairly quickly. If Bojan's work lands in bhyve, maybe that will be enough.
Comment Actions One minor thing I've noticed is that we don't export M_NOWAIT.
Comment Actions It should be, at least lets try it that way. I added M_NOWAIT into !_KERNEL block of sys/vmem.h. Also I inspected subr_vmem.c and M_WAITOK seems to be only used by the kernel blocks.
Comment Actions Set quantum to 1. |