28.07.2012 20:05, KP Kirchdoerfer пишет: > Am 28.07.2012 18:50, schrieb Andrew: >> Hi. >> >> 27.07.2012 13:50, david M brooke пишет: >>>> Also I planned to add zram support (I think that using it in usual way - >>>> as swap - should be optimal) - but it isn't showstopper for alpha >>>> release, this will be a minor change (mostly - kernel config will be >>>> changed, + small init modification, + mkswap/swapon applets in busybox >>>> should be enabled). >>>> >>>> And now we have independent userland and kernel-related packages - so we >>>> can provide multiple kernel versions for one LEAF version. Of course, >>>> this will require some rework of make scripts, and some rework of >>>> packaging scripts. IMHO this shouldn't hurt anything, but in future >>>> it'll allow to have stable LTS kernel and bleeding-edge kernel with all >>>> modern hw support inside one v5 branch. >>>> >>>> Any suggestions? >>> Wouldn't it be better to maintain different Git branches for different >>> versions of the kernel? >>> >>> dMb >>> >>> >> I think that there is no need to maintain different branches with >> similar userland. Kernel version shouldn't affect userland software. At >> least, we can try in future to provide separate kernels for single >> distro version. >> One thing that should be done on this stage - we should use not single >> version (for ex., 5.0-alpha1), but double versioning, userland and >> kernel (for ex., 5.0-alpha1/3.2.24). > Andrew; > > I agree with David. > I'm afraid this can become a support hell. It's not just the kernel, > also the kernel modules, kernel related-packages, at least 4 initrd and > initmod versions, buildimage... No, now we have single initrd for all kernels. Kernel-related packages - if they contains modules, they modules should be compiled for all kernels; and binaries are same (they aren't too heavy wired with current kernel version; for ex., I use gentoo on home server and there is a lag between kernel update and kernel headers updates, + I don't recompile all for current kernel - and I have no problems with userland that was built for old kernel with old headers). > I'm also afraid that it can become confusing for users to understand > what needs to be updated in a single version if one updates the > kernel,and even more to respind to error reports. If we'll divide userland packages and kernel/kernel-related packages (just 4 binaries - kernel, initmod, moddb, modules.tgz) - IMHO this shouldn't make a headache. And new kernel release can be done independent, not touching userland version. > I think it's simply too much to handle for the small developer team we are. > Please let's keep as simple as possible. Adding support for other > architectures is enough work, if done right, for now. > > > kp > I think that it shouldn't have any troubles in supporting. At first stage it'll be enough just to add kernel version to each BuC release, and to mention somewhere in documentation that kernel now is completely separate form userland. This shouldn't change anything, bit this will allow us to simply add new kernel to existing branch in future.
------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
