Jamie Nguyen
dysco****@gmail*****
Thu Dec 23 23:19:10 JST 2010
Tetsuo Handa wrote: > tags/lkml/ and tags/tomoyo-lsm/ contains legacy snapshots and are no longer > used. > > There are many git trees involved in linux kernel development. > > Mainline version (which will be released as stable kernel 2.6.x) is maintained > in linux-2.6 git tree. > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary > > Changes which will go into linux-2.6 git tree upon next merge window are > maintained in linux-next git tree. > http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=summary > > Changes which go into linux-next git tree are maintained in #next branch of > security-testing-2.6 git tree. > http://git.kernel.org/?p=linux/kernel/git/jmorris/security-testing-2.6.git;a=shortlog;h=refs/heads/next > > TOMOYO 2.x patches goes to #next branch of security-testing-2.6 git tree. > Currently I'm making TOMOYO 2.x patches using quilt and keeping them on > trunk/2.3.x/ . However, I was asked to maintain a public git tree which will go > into #next branch of security-testing-2.6 git tree. > http://marc.info/?l=linux-security-module&m=128862227720180&w=4 > Sooner or later, TOMOYO 2.x patches will be maintained outside SVN repository. Thanks. My knowledge of the kernel development process is a little fuzzy! If I understand correctly, I should make changes in trunk/2.3.x/ which will then be incorporated into the #next branch of security-testing-2.6 git tree when patches are ready. And in the future I should make changes in the public git tree once it is available. >> > Excuse me, I want to confirm. Do you agree with forcing users to use pipe or >> > redirection when using ccs-loadpolicy ? >> >> Yes, I agree. >> > I see. /usr/sbin/ccs-loadpolicy is currently handling > > (1) Which source (stdin or file) to use. > (2) Which policy directory (default: /etc/ccs/ ) to read from if using file as > source. > (3) Which policy file (determined from 's' 'e' 'd' 'p' 'm' options) to read > from if using file as source. > (4) Which destination ( /proc/ccs/ directory or ccs-editpolicy-agent process) > to use. > (5) Which mode (append or overwrite) to use if using 'e' or 'd' option. > > from the command line options. But if we let ccs-loadpolicy to deal only > stdin as source, we don't need to care about (1) (2) (3). > /usr/sbin/ccs-loadpolicy will become very simple. Yes, this sounds great. Kind regards
TOMOYO
Fork