Hi Herbert, Re. the perspectives you mentioned: I am definitely in the kernel integrator camp wrt vserver, so clearly my perspective is biased. I have no idea what you mean by "it's fine if the user has problems with the mainline version, it's not ours..." comment.
Based on my reading of perf. numbers published in LSM's USENIX security conference, LSM does not impact performance any more significantly than vserver does. I.e., the numbers are so small that it doesn't really appear to make a big difference. Correct me if I wrong! I cannot comment on LSM being well tested or not. More importantly, my hope is that by moving to LSM it is possible to stack other security systems on top of vserver. I.e., I am not convinced that the one provided by vserver is necessarily the right one beyond basic hosting scenarios for which vserver was originally designed. There are other scenarios where folks would benefit from vserver, but they have different security requirements. E.g., PlanetLab uses vserver, but we also permit a degree of sharing between vservers (both files and other kernel objects), which you wouldn't do in basic hosting situations. Another example might be to use vserver for "configuration isolation" on next generation consumer electronics devices (i.e., cellular phones). Such devices are starting to run Linux and manufactures want to run 3rd party apps on them without compromising "safety" of the systems main operation. Any way, I am not making this up as I have spoken to someone in this area about vserver+ckrm and they are interested --- annecdotal evidence that vserver might be used in environments other than basic hosting environments. I am not a LSM expert either. Bottom line is that we do not need to stick with the LSM API as is. Rather, where there is overlap, I am suggesting to use the LSM API. Where there is no overlap, it would be good to see whether the LSM interface needs to be extended, which I think is also a great contribution!! Thank you for the list. While CKRM currently does not support it, I think that disk limits and context quota could become a CKRM controllers. We also developed a network virtualization layer for PlanetLab, which we incidentally call vnet. The guy who did this work, Mark Huang, noticed that you also have a vnet and that there is overlap. Nonetheless, our work is not intimately tied into vserver. It can be (and probably should) remain as a separate entity. Has Mark contacted you about this yet? I'll get back to your detailed list at some other point in time. cheers, Marc _______________________________________________ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
