Re: Additional kernel options and devices
2011/2/8 Guillem Jover : > [...] upstream might not > have enabled them because they are not deemed ready for wider use, > for stability, performance, or other reasons. > > A possible solution to this could be to build another kernel image > flavour with some default diverging options enabled, and once and if > they have been tested successfully we could consider moving specific > ones to the main images. Wouldn't experimental be a better place for this? Or even, a separate package that tracks -current. Then it'd accomplish the goal you describe, plus other kind of testing at the same time. But that possibly requires more manpower. -- Robert Millan -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTinVGH=44vhhew8tcs2rgf6sgg+avraqteoja...@mail.gmail.com
Re: Additional kernel options and devices
Hi! On Tue, 2011-02-08 at 18:55:25 +0100, Petr Salinger wrote: > >If you and other are of the view that the BTS is the best > >first step, then I will abide that mechanism of raising any > >issues concerning the capacity of the packaged kernel. > > The mails into BTS are forwarded to maintainer e-mail > (which is debian-bsd@lists.debian.org). > > So discussion takes place on this list and is stored in BTS. Right, but I think a wiki page with the summary and the rationale for the specific options would be easier to handle, than having to crawl the bug report or the list archive. > >When writing "central information source" I loosely imagined > >some sight at Alioth or wiki.d.o display or mentioning in what > >sense kFreeBSD is advancing ahead of FreeBSD proper regarding > >default device support. (Sorry for the lengthy explanation.) > > In wiki, there might be summary of changes (like enabled quota), > but detailed reasoning would be stored in BTS (and list archive). > > We might also alter our kernel config files into: > - [...] > --- > > This way would be clearer our difference against upstream GENERIC. That'd work fine for uncontroversial changes, or things that are known not to possibly break the rest of the kernel functionality. I guess the question here is to what extent we want to diverge from upstream default options? And on which cases, given that upstream might not have enabled them because they are not deemed ready for wider use, for stability, performance, or other reasons. A possible solution to this could be to build another kernel image flavour with some default diverging options enabled, and once and if they have been tested successfully we could consider moving specific ones to the main images. regards, guillem -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110208193605.ga5...@gaara.hadrons.org
Re: Additional kernel options and devices
Mats Erik Andersson writes: > Anyway, there is certainly functionality that is not default > in upstream FreeBSD, but could justly be considered mandatory > for GNU/kFreeBSD. Could we collect some kind of central information > source on this matter? Thanks for the reminder. I added == Q. How does kfreebsd's config differ from upstream and why? == A. You can [[http://svn.debian.org/wsvn/glibc-bsd/trunk/kfreebsd-8/debian/patches/999_config.diff|take a look at the changes made to sys/amd64/conf/GENERIC]]. to http://wiki.debian.org/Debian_GNU/kFreeBSD_FAQ -- would the ideal place to document the rationale behind each change be in the description of that patch? I am not sure if it is good to have it separately in the wiki when it could be in the patch itself. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/84r5biwdia@sauna.l.org
Re: Additional kernel options and devices
A particular example I have encounterd is "ipsec-tools" where a recent upload aims at adaptions to BSD, but where the present kernel is neither supporting the API, nor the relevant devices. Here I will prepare information for making an official decision in the end, but other cases are certain to exist in cases where the capability in question is implicit to us within GNU/Linux, but needs a decision for GNU/kFreeBSD. If you and other are of the view that the BTS is the best first step, then I will abide that mechanism of raising any issues concerning the capacity of the packaged kernel. The mails into BTS are forwarded to maintainer e-mail (which is debian-bsd@lists.debian.org). So discussion takes place on this list and is stored in BTS. When writing "central information source" I loosely imagined some sight at Alioth or wiki.d.o display or mentioning in what sense kFreeBSD is advancing ahead of FreeBSD proper regarding default device support. (Sorry for the lengthy explanation.) In wiki, there might be summary of changes (like enabled quota), but detailed reasoning would be stored in BTS (and list archive). We might also alter our kernel config files into: - include GENERIC include DEBIAN options SMP options ALTQ_NOPCC # Required for SMP build makeoptions COPTFLAGS="-O2 -frename-registers -pipe -march=i686 -mtune=generic" and DEBIAN would contain --- nodevice fdc # Alternate queueing options ALTQ options ALTQ_CBQ# Class Bases Queuing (CBQ) options ALTQ_RED# Random Early Detection (RED) options ALTQ_RIO# RED In/Out options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) options ALTQ_PRIQ # Priority Queuing (PRIQ) options ALTQ_NOPCC # Required for SMP build # kFreeBSD needs options COMPAT_LINUX options LINPROCFS options LINSYSFS options FDESCFS options TMPFS # raise shared memory limits options SHMMAXPGS=4096 options SHMSEG=256 options SEMMNI=256 options SEMMNS=512 options SEMMNU=256 options SEMMAP=256 # quota is supported, see freebsd-quota package for userland option QUOTA --- This way would be clearer our difference against upstream GENERIC. BTW, what is the state of quota support in userland ? Petr -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.62.1102081833190.23...@sci.felk.cvut.cz
Re: Additional kernel options and devices
2011/2/8 Mats Erik Andersson : > If you and other are of the view that the BTS is the best > first step, then I will abide that mechanism of raising any > issues concerning the capacity of the packaged kernel. That's my first impression, but keep in mind my voice is not authoritative. I'm just providing advice. > When writing "central information source" I loosely imagined > some sight at Alioth or wiki.d.o display or mentioning in what > sense kFreeBSD is advancing ahead of FreeBSD proper regarding > default device support. (Sorry for the lengthy explanation.) Maybe you could try and see how it works out. Anyone can create wiki pages in wiki.d.o AFAIK. -- Robert Millan -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktiknt3nfn6nt3xrrr1vxh1wlwu_l_xgirwzbd...@mail.gmail.com
Re: Additional kernel options and devices
tisdag den 8 februari 2011 klockan 15:50 skrev Robert Millan detta: > 2011/2/8 Mats Erik Andersson : > > Anyway, there is certainly functionality that is not default > > in upstream FreeBSD, but could justly be considered mandatory > > for GNU/kFreeBSD. Could we collect some kind of central information > > source on this matter? > > I would suggest using the BTS for this. Is that what you had > in mind? Not exactly. I read into the message sent by Axel Beckert a desire to discuss to what extent GNU/kFreeBSD could go further than FreeBSD does, in the sense of activating in an official kfreebds-image_### some options or devices that are not included in a GENERIC setting for the upstream kernel; and then discuss what the consequences would be. I see a potential problem in packaged software ported for GNU/kFreeBSD where the kernel setting is not keeping pace. A particular example I have encounterd is "ipsec-tools" where a recent upload aims at adaptions to BSD, but where the present kernel is neither supporting the API, nor the relevant devices. Here I will prepare information for making an official decision in the end, but other cases are certain to exist in cases where the capability in question is implicit to us within GNU/Linux, but needs a decision for GNU/kFreeBSD. If you and other are of the view that the BTS is the best first step, then I will abide that mechanism of raising any issues concerning the capacity of the packaged kernel. When writing "central information source" I loosely imagined some sight at Alioth or wiki.d.o display or mentioning in what sense kFreeBSD is advancing ahead of FreeBSD proper regarding default device support. (Sorry for the lengthy explanation.) Regards, Mats E A -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110208155333.gb25...@mea.homelinux.org
Re: Additional kernel options and devices
On 02-08 14:49, Mats Erik Andersson wrote: > Dear all, > > let me initiate a spinoff subject related to Axel Beckert's > followup from the FOSDEM meeting. > > My interest in activating > >option QUOTA > > is well known. My work from last week points also to > >option IPSEC >option IPSEC_NAT_T >device crypto >device enc > > However, I have identified two issues in ipsec-tools/racoon > that are incorrect also for FreeBSD and appearently have gone > unnoticed. One issue is resolved already and will go upstream > to ipsec-tools within shortly, the other one will be examined > this week. > > Anyway, there is certainly functionality that is not default > in upstream FreeBSD, but could justly be considered mandatory > for GNU/kFreeBSD. Could we collect some kind of central information > source on this matter? > > If somebody could provide packaged kernel and racoon, I can test it, especially interoperability with linux machines, as I use native ipsec a lot in few networks. -- Witold Baryluk signature.asc Description: Digital signature
Re: Additional kernel options and devices
2011/2/8 Mats Erik Andersson : > Anyway, there is certainly functionality that is not default > in upstream FreeBSD, but could justly be considered mandatory > for GNU/kFreeBSD. Could we collect some kind of central information > source on this matter? I would suggest using the BTS for this. Is that what you had in mind? -- Robert Millan -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTimdzKVPduqBkYQEhTtySt4rurb3mSHtJBZ=h...@mail.gmail.com
Additional kernel options and devices
Dear all, let me initiate a spinoff subject related to Axel Beckert's followup from the FOSDEM meeting. My interest in activating option QUOTA is well known. My work from last week points also to option IPSEC option IPSEC_NAT_T device crypto device enc However, I have identified two issues in ipsec-tools/racoon that are incorrect also for FreeBSD and appearently have gone unnoticed. One issue is resolved already and will go upstream to ipsec-tools within shortly, the other one will be examined this week. Anyway, there is certainly functionality that is not default in upstream FreeBSD, but could justly be considered mandatory for GNU/kFreeBSD. Could we collect some kind of central information source on this matter? Best regards, Mats Erik Andersson, DM -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110208134949.ga24...@mea.homelinux.org
