Hi! > >> Hmm, so the suggestion is to have some directory which contains files > >> representing IDs, each containing the string name of the associated > >> vma? Then let's say we are creating a new VMA and want to name it. We > >> would have to scan that directory, check all files and see if any of > >> them contain the name we want to reuse the same ID. > > > > I believe Pavel meant something as simple as > > $ YOUR_FILE=$YOUR_IDS_DIR/my_string_name > > $ touch $YOUR_FILE > > $ stat -c %i $YOUR_FILE > > So in terms of syscall overhead, that would be open(..., O_CREAT | > O_CLOEXEC), fstat(), close() - or one could optimistically start by You could get to two if you used mkdir instead of open. > > YOUR_IDS_DIR can live on a tmpfs and you can even implement a policy on > > top of that (who can generate new ids, gurantee uniqness etc...). > > > > The above is certainly not for free of course but if you really need a > > system wide consistency when using names then you need some sort of > > central authority. How you implement that is not all that important > > but I do not think we want to handle that in the kernel. > > IDK. If the whole thing could be put behind a CONFIG_ knob, with _zero_ > overhead when not enabled (and I'm a bit worried about all the functions > that grow an extra argument that gets passed around), I don't mind the > string interface. But I don't really have a say either way. If this is ever useful outside of Android, eventually distros will have it enabled. Best regards, Pavel -- http://www.livejournal.com/~pavelmachek
Attachment:
signature.asc
Description: PGP signature
