Re: generalized mergemaster(8)
On Thu, Mar 20, 2003 at 10:15:48PM -0600, Brandon D. Valentine wrote: I have encountered a situation in which it would be extremely handy to have a generalized version of mergemaster(8) which is less specific to the task of merging /etc. I need to recursively merge two directories of source files in which I wish to preserve some original files, install some replacement files outright, and only actually go to the trouble of sdiff(1)ing those files that from the preview udiff look like they are need of a merge. Have you considered emacs ediff-directories? It might be better suited than mergemaster for handling arbitrary directories. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: generalized mergemaster(8)
[ This email edited in vim. ] On Fri, Mar 21, 2003 at 07:21:08PM +1100, Peter Jeremy wrote: Have you considered emacs ediff-directories? It might be better suited than mergemaster for handling arbitrary directories. No, I have not considered it. ;-) As for mergemaster, it just about works for arbitrary directories. I've been playing around with it locally and there's not much effort needed to generalize it. The only challenge is maintaining POLA wrt people using mergemaster for its intended purpose, updating /etc post-installworld, without having the general functionality seem like a hack. I've got it working well enough for what I needed it for, but if there is interest I will cleanup the patches so they're POLA-safe and post them here. Brandon D. Valentine -- [EMAIL PROTECTED] http://www.geekpunk.net Pseudo-Random Googlism: valentine is the most precocious foal i have ever met To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
bug in subr_bus.c?
Hello, It's been a while since I've been doing FreeBSD work, but I was recently working on a device driver for the Pinicle Micro DC10+ (Zoran chip) video en/decoder board and was making full use of the newbus system. I've been doing my devel work on 5.0-R (I'm in Thailand right now so I don't have my normal devel environment) and doing it all on KLD to help speed up devel. Right now the problem I have is on kldunload, devclass_delete_driver gets called and calls the detach routine for all associated devices. This is a slight problem since device_detach doesn't know anything about the children, and if you look at device_delete_child, it deletes all the children, and then calls detach. So, the driver can: a) delete it's own children, but if it gets removed via device_delete_child, this work is already down for you. b) let the bus code remove your children, but then if you're a kld, your children won't be removed and you will cause a panic in devinfo and other nasties since a device's parent won't exist anymore. I believe that devclass_delete_driver should do a device_delete_child instead of a simple detach, but then there is much code that is broken in that it assumes that it needs to delete it's own children. So, do we have the *_detach routine delete it's children or have the bus code do it? If you look at sys/dev/iicbus/iicbb.c, in the detach routine it delete's the iicbus child, but that would already be gone in the delete_child case, but not in the simple detach case. So, which is correct? I'll fix this, but I need direction on which way to go. I think that letting the bus code delete the children is better. Comments? btw, I will post some scripts to autoload kld debug symbols to my home page (http://people.freebsd.org/~jmg/) soon. John-Mark Gurney To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: bug in subr_bus.c?
On Fri, 21 Mar 2003, John-Mark Gurney wrote: So, the driver can: a)delete it's own children, but if it gets removed via device_delete_child, this work is already down for you. If you create children then you're going to be involved in removing them. There are helper routines that simplify some operations but I don't believe any changes to subr_bus.c are needed. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Build options for kernel modules
On Fri, Mar 21, 2003 at 06:32:17PM +0300, Yar Tikhiy wrote: Hi there, Excuse my stupid question, but I seem to have no time to do the investigation by myself right now so I'd be glad to receive a brief answer from someone who has the information. As far as I can see, kernel modules should be built along with the kernel for the only reason of keeping their mutual interfaces in sync, has a source file defining such an interface changed. Is there currently no way to go further and affect a kernel module's built-in features with kernel config file options, besides modifying makefiles in /sys/modules? There is. It's called ``makeoptions''. It's passed to both kernel and modules builds. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age pgp0.pgp Description: PGP signature
Re: Build options for kernel modules
On Fri, Mar 21, 2003 at 06:32:17PM +0300, Yar Tikhiy wrote: Hi there, Excuse my stupid question, but I seem to have no time to do the investigation by myself right now so I'd be glad to receive a brief answer from someone who has the information. As far as I can see, kernel modules should be built along with the kernel for the only reason of keeping their mutual interfaces in sync, has a source file defining such an interface changed. Is there currently no way to go further and affect a kernel module's built-in features with kernel config file options, besides modifying makefiles in /sys/modules? I think this isn't so. I have been already tried to compile some modules without compiling kernel and this trye has successful result, but without change options. I think modules must be build with same or less imports and same or more export to be correct for loading. -- With best wishes Nikolay mail: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: generalized mergemaster(8)
What we need is a way to mark some package files as customizeable files, or configuration files. The same way that some files are marked DOC, but a bit better: it would need to be carried to the installed package database. This is again re-inventing the wheel since it is exactly how Debian's apt-get system deals with configuration files. /etc files are part of a package that, when upgraded, are checked for modification and the user is offered the choice similar to mergemaster to install, merge, or just delete. We still need to write a generic tool to diff and merge. It's not so hard to write. It would basically be a stripped down version of mergemaster -s. I think such a tool would be really useful. A. On Thu Mar 20, 2003 at 10:15:48PM -0600, Brandon D. Valentine wrote: I have encountered a situation in which it would be extremely handy to have a generalized version of mergemaster(8) which is less specific to the task of merging /etc. I need to recursively merge two directories of source files in which I wish to preserve some original files, install some replacement files outright, and only actually go to the trouble of sdiff(1)ing those files that from the preview udiff look like they are need of a merge. Has anyone already done the work of generalizing mergemaster to this more general task? And if not, is there interest in this? If nobody has done it I'm probably about to. My inclination is to extend the existing mergemaster script to support this general functionality while maintaining support for the specific case of an /etc merge. mergemaster(8) is already fairly applicable to this task but it currently makes some assumptions about what your $Id$ looks like and that you will in fact be running make(1) somewhere to generate your temproot. Thoughts? Brandon D. Valentine -- [EMAIL PROTECTED] http://www.geekpunk.net Pseudo-Random Googlism: valentine is her husband To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- Advertisers, not governments, are the primary censors of media content in the United States today. - C. Edwin Baker http://www.ad-mad.co.uk/quotes/freespeech.htm pgp0.pgp Description: PGP signature
Re: Build options for kernel modules
On Fri, Mar 21, 2003 at 05:39:07PM +0200, Nikolay Y. Orlyuk wrote: On Fri, Mar 21, 2003 at 06:32:17PM +0300, Yar Tikhiy wrote: Hi there, Excuse my stupid question, but I seem to have no time to do the investigation by myself right now so I'd be glad to receive a brief answer from someone who has the information. As far as I can see, kernel modules should be built along with the kernel for the only reason of keeping their mutual interfaces in sync, has a source file defining such an interface changed. Is there currently no way to go further and affect a kernel module's built-in features with kernel config file options, besides modifying makefiles in /sys/modules? I think this isn't so. I have been already tried to compile some modules without compiling kernel and this trye has successful result, but without change options. I think modules must be build with same or less imports and same or more export to be correct for loading. Yeah, it's all right to compile modules w/o the kernel, but that's not exactly what I was asking about. My question was whether option FOO lines from a kernel configuration file could influence modules. -- Yar To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Build options for kernel modules
On Fri Mar 21, 2003 at 07:16:58PM +0300, Yar Tikhiy wrote: On Fri, Mar 21, 2003 at 05:39:07PM +0200, Nikolay Y. Orlyuk wrote: On Fri, Mar 21, 2003 at 06:32:17PM +0300, Yar Tikhiy wrote: Hi there, Excuse my stupid question, but I seem to have no time to do the investigation by myself right now so I'd be glad to receive a brief answer from someone who has the information. As far as I can see, kernel modules should be built along with the kernel for the only reason of keeping their mutual interfaces in sync, has a source file defining such an interface changed. Is there currently no way to go further and affect a kernel module's built-in features with kernel config file options, besides modifying makefiles in /sys/modules? I think this isn't so. I have been already tried to compile some modules without compiling kernel and this trye has successful result, but without change options. I think modules must be build with same or less imports and same or more export to be correct for loading. Yeah, it's all right to compile modules w/o the kernel, but that's not exactly what I was asking about. My question was whether option FOO lines from a kernel configuration file could influence modules. I'm pretty sure they do. A great example is IPFIREWALL_* options: if they don't influence the module, I think we have a problem. ;) A. -- Advertisers, not governments, are the primary censors of media content in the United States today. - C. Edwin Baker http://www.ad-mad.co.uk/quotes/freespeech.htm pgp0.pgp Description: PGP signature
Re: Build options for kernel modules
On Fri, Mar 21, 2003 at 05:35:22PM +0200, Ruslan Ermilov wrote: On Fri, Mar 21, 2003 at 06:32:17PM +0300, Yar Tikhiy wrote: Hi there, Excuse my stupid question, but I seem to have no time to do the investigation by myself right now so I'd be glad to receive a brief answer from someone who has the information. As far as I can see, kernel modules should be built along with the kernel for the only reason of keeping their mutual interfaces in sync, has a source file defining such an interface changed. Is there currently no way to go further and affect a kernel module's built-in features with kernel config file options, besides modifying makefiles in /sys/modules? There is. It's called ``makeoptions''. It's passed to both kernel and modules builds. I beg your pardon, but makeoptions is just next to editing makefiles in /sys/modules. My dream was that specifying, e.g., options IPFIREWALL_VERBOSE would result in building ipfw.ko inherently chatty :-) BTW, Ruslan, let me ask you another question, as you've been recently working at kern.mk files. Is it on purpose that the target kernel-cleandir doesn't invoke kernel-cleandepend? I've been sure that by common practice cleandir should remove dependency files... -- Yar To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
ᨡ¿ÃÕ ! ˹ѧÊ×ͤÙèÁ×ͤ¹à¤Â¨¹ ÊÓËÃѺ¼Ùéʹã¨....
·Ó§Ò¹·ÕèÂÒ¡·ÕèÊØ´¡è͹ ¼ÁÂÔè§ÁÕªÕÇÔµÍÂÙè¹Ò¹à·èÒäËÃè ¼ÁÂÔè§ÁÑè¹ã¨ÁÒ¡¢Öé¹à·èÒ¹Ñé¹ ÇèÒ¤ÇÒÁᵡµèÒ§ÍѹÂÔè§ãËèÃÐËÇèÒ§Á¹ØÉÂì... ÃÐËÇèÒ¤¹·ÕèÍè͹áÍáÅФ¹·ÕÍÓ¹Ò¨... ÃÐËÇèÒ§¤¹·ÕèÂÔè§ãËèáÅФ¹·ÕèäÁèÊÓ¤Ñ ¡ç¤×Í àÃÕèÂÇáç¢Í§¤ÇÒÁµÑé§ã¨á¹èÇá¹è·ÕèäÁèÍÒ¨·ÓÅÒÂä´é ¨Ø´»ÃÐʧ¤ì·ÕèàÁ×è͵Ñ駢Öé¹áÅéÇ ¶éÒäÁèµÒ¡çµéͧª¹Ð -à«ÍÃìâ¸ÁÑÊ ¿ÒÇàÇÅ ºÑê¡«ìµÑ¹ ˹Öè§ã¹à·¤¹Ô¤·Õè´Õ·ÕèÊش㹡ÒÃàÍÒª¹Ð¹ÔÊѼѴÇѹ»ÃСѹ¾ÃØè§ áÅзӧҹä´éÁÒ¡¢Öé¹áÅÐàÃçÇ¢Ö鹡ç¤×ÍŧÁ×Í·Ó§Ò¹·ÕèÂÒ¡·ÕèÊØ´¢Í§¤Ø³¡è͹ ¹Õè¤×Í¡Òà ¡Ô¹¡º¢Í§¤Ø³ ·Õèá·é¨ÃÔ§ Áѹà»ç¹·Ñ¡ÉÐÊèǹºØ¤¤Å㹡ÒúÃÔËÒà ·ÕèÂÒ¡·ÕèÊØ´áÅÐÊӤѷÕèÊØ´àÃÔèÁµé¹µÍ¹àªéÒ´éǧҹ·ÕèãËè·ÕèÊØ´áÅÐÊӤѷÕèÊØ´ ¤×Í ÊÔ觵ç¢éÒÁ¡Ñº·Õ褹ÊèǹãËè·Ó ÃÐàºÕºÇԹѹÕé¨Ð·ÓãËé¤Ø³àÅÔ¡¹ÔÊÑ ¼Ñ´Çѹ »ÃСѹ¾ÃØè§áÅзÓãËé͹ҤµÍÂÙè㹡ÓÁ×ͤس ¡ÒÃàÃÔèÁµé¹áµèÅÐÇѹ´éǧҹ·ÕèÂÒ¡·ÕèÊØ´à»ç¹¡ÒÃàÃÔèÁµé¹áºº¡éÒÇ¡ÃÐâ´´ ·Õè´Õ ¤Ø³¨ÐÁÕä¿ÁÒ¡¢Öé¹ áÅШзӧҹä´é¼Å´ÕÁÒ¡¢Öé¹ ã¹Çѹ·Õè¤Ø³àÃÔèÁŧÁ×Í·Ó§Ò¹ÊÓ¤Ñâ´Â·Ñ¹·Õ·Ñ¹¤Çѹ ¤Ø³¨ÐÃÙéÊÖ¡´Õ¡ÑºµÑÇ ¤Ø³àͧáÅСѺ§Ò¹¢Í§¤Ø³ÁÒ¡¡ÇèÒ¤¹Í×è¹æ ¤Ø³¨ÐÃÙéÊÖ¡ÁÕÍÓ¹Ò¨ÁÒ¡¢Öé¹ ¤Çº¤ØÁ µÑÇàͧä´éÁÒ¡¢Öé¹áÅÐÃѺ¼Ô´ªÍº´ÙáŪÕÇÔµµÑÇàͧä´éÁÒ¡¡ÇèÒàÇÅÒÍ×è¹ ÊÃéÒ§¹ÔÊÑÂàÃÔèÁ·Ó§Ò¹·ÕèÂÒ¡·ÕèÊØ´¡è͹áÅéǤس¨ÐäÁèµéͧÁͧÂé͹¡ÅѺ ¤Ø³¨Ð¡ÅÒÂà»ç¹ ˹Öè§ã¹¤¹·ÕèÁÕ»ÃÐÊÔ·¸ÔÀÒ¾ÁÒ¡·ÕèÊش㹤¹ÃØ蹤س... ¡Ô¹¡ºµÑǹÑ鹫Ð!!! ¨§ÁͧµÑÇàͧÇèÒà»ç¹§Ò¹·Õè¡ÓÅѧ¤×ºË¹éÒ ¨§à·ã¨ãËé¡Ñº¡ÒÃà¾ÒйÔÊÑ à»ç¹¤¹ÁռŧҹÊÙ§´éÇ¡Òý֡«éÓáÅéÇ«éÓàÅèÒ¨¹¡ÃзÑè§Áѹ¡ÅÒÂà»ç¹àÃ×èͧÍѵâ¹ÁѵÔáÅÐ ¡ÅÒÂà»ç¹àÃ×èͧ§èÒ ˹Öè§ã¹ÇÅÕ·ÕèÁÕ͹ØÀÒ¾ÁÒ¡·ÕèÊØ´«Ö觤سÊÒÁÒöàÃÕ¹ÃÙéáÅйÓÁÒãªéä´é¡ç¤×Í à¾×èÍÇѹ¹Õéà·èÒ¹Ñé¹! ÍÂèÒÇÔµ¡àÃ×èͧ¡ÒÃà»ÅÕè¹á»Å§ªÕÇÔµµÑÇàͧ ¶éÒÁѹ¿Ñ§àËÁ×͹à»ç¹ ¤ÇÒÁ¤Ô´·Õè´Õ ¨§·ÓÁѹ à¾×èÍÇѹ¹Õéà·èÒ¹Ñé¹ ºÍ¡¡ÑºµÑÇàͧÇèÒ à¾×èÍÇѹ¹Õéà·èÒ¹Ñé¹ ©Ñ¹¨ÐÇҧἹàµÃÕÂÁ¡Òà áÅÐàÃÔèÁµé¹§Ò¹ ·ÕèÂÒ¡·ÕèÊØ´¡è͹¨Ð·ÓÍÂèÒ§Í×è¹ áÅéǤس¨Ðµéͧ·Ö觡Ѻ¤ÇÒÁᵡµèÒ§·Õèà¡Ô´¢Öé¹ã¹ªÕÇÔµ¤Ø³ -- ¤Ø³ ¾ÃéÍÁáÅéÇÃÖÂѧ ¡ÑºÃٻẺ¡Ò÷ӧҹ§èÒÂæ¨Ò¡·ÕèºéÒ¹ Click Here! www.geocities.com/thaigetrich/easywork , ËÃ×Í Tel. 0-2277-7850 ¡´ 25 --- ¢ÍÍÀÑÂËÒ¡à»ç¹¡ÒÃú¡Ç¹ áÅÐËÒ¡äÁèµéͧ¡ÒÃãËéÊ觢èÒÇÊÒÃÁÒÂѧ·èÒ¹ÍÕ¡ ¡ÃسÒàÁÅÅìÁÒ·Õè [EMAIL PROTECTED] ËÑÇ¢éÍ unsub
Re: Build options for kernel modules
On Fri, 21 Mar 2003, The Anarcat wrote: TAOn Fri Mar 21, 2003 at 07:16:58PM +0300, Yar Tikhiy wrote: TA On Fri, Mar 21, 2003 at 05:39:07PM +0200, Nikolay Y. Orlyuk wrote: TA On Fri, Mar 21, 2003 at 06:32:17PM +0300, Yar Tikhiy wrote: TA Hi there, TA TA Excuse my stupid question, but I seem to have no time to do the TA investigation by myself right now so I'd be glad to receive a brief TA answer from someone who has the information. TA TA As far as I can see, kernel modules should be built along with the TA kernel for the only reason of keeping their mutual interfaces in TA sync, has a source file defining such an interface changed. Is TA there currently no way to go further and affect a kernel module's TA built-in features with kernel config file options, besides modifying TA makefiles in /sys/modules? TA I think this isn't so. I have been already tried to compile some modules TA without compiling kernel and this trye has successful result, but without TA change options. TA I think modules must be build with same or less imports and same or more export to be correct TA for loading. TA TA Yeah, it's all right to compile modules w/o the kernel, but that's TA not exactly what I was asking about. My question was whether option TA FOO lines from a kernel configuration file could influence modules. TA TAI'm pretty sure they do. A great example is IPFIREWALL_* options: if TAthey don't influence the module, I think we have a problem. ;) How should they? The Makefiles for modules usually create the option files that normally are create by config options themself and set the options to 1. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
ᨡ¿ÃÕ ! ˹ѧÊ×ͤÙèÁ×ͤ¹à¤Â¨¹ ÊÓËÃѺ¼Ùéʹã¨....
·Ó§Ò¹·ÕèÂÒ¡·ÕèÊØ´¡è͹ ¼ÁÂÔè§ÁÕªÕÇÔµÍÂÙè¹Ò¹à·èÒäËÃè ¼ÁÂÔè§ÁÑè¹ã¨ÁÒ¡¢Öé¹à·èÒ¹Ñé¹ ÇèÒ¤ÇÒÁᵡµèÒ§ÍѹÂÔè§ãËèÃÐËÇèÒ§Á¹ØÉÂì... ÃÐËÇèÒ¤¹·ÕèÍè͹áÍáÅФ¹·ÕÍÓ¹Ò¨... ÃÐËÇèÒ§¤¹·ÕèÂÔè§ãËèáÅФ¹·ÕèäÁèÊÓ¤Ñ ¡ç¤×Í àÃÕèÂÇáç¢Í§¤ÇÒÁµÑé§ã¨á¹èÇá¹è·ÕèäÁèÍÒ¨·ÓÅÒÂä´é ¨Ø´»ÃÐʧ¤ì·ÕèàÁ×è͵Ñ駢Öé¹áÅéÇ ¶éÒäÁèµÒ¡çµéͧª¹Ð -à«ÍÃìâ¸ÁÑÊ ¿ÒÇàÇÅ ºÑê¡«ìµÑ¹ ˹Öè§ã¹à·¤¹Ô¤·Õè´Õ·ÕèÊش㹡ÒÃàÍÒª¹Ð¹ÔÊѼѴÇѹ»ÃСѹ¾ÃØè§ áÅзӧҹä´éÁÒ¡¢Öé¹áÅÐàÃçÇ¢Ö鹡ç¤×ÍŧÁ×Í·Ó§Ò¹·ÕèÂÒ¡·ÕèÊØ´¢Í§¤Ø³¡è͹ ¹Õè¤×Í¡Òà ¡Ô¹¡º¢Í§¤Ø³ ·Õèá·é¨ÃÔ§ Áѹà»ç¹·Ñ¡ÉÐÊèǹºØ¤¤Å㹡ÒúÃÔËÒà ·ÕèÂÒ¡·ÕèÊØ´áÅÐÊӤѷÕèÊØ´àÃÔèÁµé¹µÍ¹àªéÒ´éǧҹ·ÕèãËè·ÕèÊØ´áÅÐÊӤѷÕèÊØ´ ¤×Í ÊÔ觵ç¢éÒÁ¡Ñº·Õ褹ÊèǹãËè·Ó ÃÐàºÕºÇԹѹÕé¨Ð·ÓãËé¤Ø³àÅÔ¡¹ÔÊÑ ¼Ñ´Çѹ »ÃСѹ¾ÃØè§áÅзÓãËé͹ҤµÍÂÙè㹡ÓÁ×ͤس ¡ÒÃàÃÔèÁµé¹áµèÅÐÇѹ´éǧҹ·ÕèÂÒ¡·ÕèÊØ´à»ç¹¡ÒÃàÃÔèÁµé¹áºº¡éÒÇ¡ÃÐâ´´ ·Õè´Õ ¤Ø³¨ÐÁÕä¿ÁÒ¡¢Öé¹ áÅШзӧҹä´é¼Å´ÕÁÒ¡¢Öé¹ ã¹Çѹ·Õè¤Ø³àÃÔèÁŧÁ×Í·Ó§Ò¹ÊÓ¤Ñâ´Â·Ñ¹·Õ·Ñ¹¤Çѹ ¤Ø³¨ÐÃÙéÊÖ¡´Õ¡ÑºµÑÇ ¤Ø³àͧáÅСѺ§Ò¹¢Í§¤Ø³ÁÒ¡¡ÇèÒ¤¹Í×è¹æ ¤Ø³¨ÐÃÙéÊÖ¡ÁÕÍÓ¹Ò¨ÁÒ¡¢Öé¹ ¤Çº¤ØÁ µÑÇàͧä´éÁÒ¡¢Öé¹áÅÐÃѺ¼Ô´ªÍº´ÙáŪÕÇÔµµÑÇàͧä´éÁÒ¡¡ÇèÒàÇÅÒÍ×è¹ ÊÃéÒ§¹ÔÊÑÂàÃÔèÁ·Ó§Ò¹·ÕèÂÒ¡·ÕèÊØ´¡è͹áÅéǤس¨ÐäÁèµéͧÁͧÂé͹¡ÅѺ ¤Ø³¨Ð¡ÅÒÂà»ç¹ ˹Öè§ã¹¤¹·ÕèÁÕ»ÃÐÊÔ·¸ÔÀÒ¾ÁÒ¡·ÕèÊش㹤¹ÃØ蹤س... ¡Ô¹¡ºµÑǹÑ鹫Ð!!! ¨§ÁͧµÑÇàͧÇèÒà»ç¹§Ò¹·Õè¡ÓÅѧ¤×ºË¹éÒ ¨§à·ã¨ãËé¡Ñº¡ÒÃà¾ÒйÔÊÑ à»ç¹¤¹ÁռŧҹÊÙ§´éÇ¡Òý֡«éÓáÅéÇ«éÓàÅèÒ¨¹¡ÃзÑè§Áѹ¡ÅÒÂà»ç¹àÃ×èͧÍѵâ¹ÁѵÔáÅÐ ¡ÅÒÂà»ç¹àÃ×èͧ§èÒ ˹Öè§ã¹ÇÅÕ·ÕèÁÕ͹ØÀÒ¾ÁÒ¡·ÕèÊØ´«Ö觤سÊÒÁÒöàÃÕ¹ÃÙéáÅйÓÁÒãªéä´é¡ç¤×Í à¾×èÍÇѹ¹Õéà·èÒ¹Ñé¹! ÍÂèÒÇÔµ¡àÃ×èͧ¡ÒÃà»ÅÕè¹á»Å§ªÕÇÔµµÑÇàͧ ¶éÒÁѹ¿Ñ§àËÁ×͹à»ç¹ ¤ÇÒÁ¤Ô´·Õè´Õ ¨§·ÓÁѹ à¾×èÍÇѹ¹Õéà·èÒ¹Ñé¹ ºÍ¡¡ÑºµÑÇàͧÇèÒ à¾×èÍÇѹ¹Õéà·èÒ¹Ñé¹ ©Ñ¹¨ÐÇҧἹàµÃÕÂÁ¡Òà áÅÐàÃÔèÁµé¹§Ò¹ ·ÕèÂÒ¡·ÕèÊØ´¡è͹¨Ð·ÓÍÂèÒ§Í×è¹ áÅéǤس¨Ðµéͧ·Ö觡Ѻ¤ÇÒÁᵡµèÒ§·Õèà¡Ô´¢Öé¹ã¹ªÕÇÔµ¤Ø³ -- ¤Ø³ ¾ÃéÍÁáÅéÇÃÖÂѧ ¡ÑºÃٻẺ¡Ò÷ӧҹ§èÒÂæ¨Ò¡·ÕèºéÒ¹ Click Here! www.geocities.com/thaigetrich/easywork , ËÃ×Í Tel. 0-2277-7850 ¡´ 25 --- ¢ÍÍÀÑÂËÒ¡à»ç¹¡ÒÃú¡Ç¹ áÅÐËÒ¡äÁèµéͧ¡ÒÃãËéÊ觢èÒÇÊÒÃÁÒÂѧ·èÒ¹ÍÕ¡ ¡ÃسÒàÁÅÅìÁÒ·Õè [EMAIL PROTECTED] ËÑÇ¢éÍ unsub
ld.so and hard links
Hi.
This is a really specific, technical question (and I think it's
fascinating to those of us who don't know the answer) about how the text
(code) segment of a program gets loaded into memory. I'm hoping hackers
is the right place for this. If not, please forgive and suggest another
venue.
Here's my baseline assumption. If I'm wrong here, I'm only going to get
wronger as I go:
If I have two different programs that both use a shared library,
libfoo.so, the system memory maps the object code they need into the
processes' address spaces. There's only one copy of libfoo.so in memory,
and the two processes each have handles into it (or maybe just to the
pieces of it that they use?).
Step 2 of my question. This gets closer to my real query:
Ok now consider a hard link (not a symlink) from libfoo.so to libbar.so.
One inode, two directory entries. Consider my two programs again, one
linked against libfoo.so and the other linked against libbar.so. When
they run, how many copies of the lib{foo,bar}.so object code are in RAM?
My current hypothesis is 1. Isn't it mmapped off the disk? The inode
matters, not the file name, right? With me so far? Great.
Now consider jail(8). Let's say I have two jail environments (If you
think I mean chroot here, go read jail(8), it's not the same. I'm
assuming folks on hackers know jail.). To make my first jail, I make a
copy of the FreeBSD stuff that my jail needs. To make the second jail, I
create a directory hiearachy, but I *hard link* all the binaries and
libraries and stuff to the same inodes that the first jail uses. Is that
clear? Let's pick a specific example: 'ln /jail1/usr/sbin/sshd
/jail2/usr/sbin/sshd'. Now, sshd uses /usr/lib/libz.so.2. In my example,
I have (effectively) done 'ln /jail1/usr/lib/libz.so.2
/jail2/usr/lib/libz.so.2'. These are not symlinks, so this works across
jails. Now I launch both jails. Two sshd processes are running, one in
each jail.
Now the $64K question: How many instances of, for example, the libz.so.2
object code are in memory? Did my use of jail(8) make any difference? My
intuition is that only one copy of the code is in memory for the same
reason as in step 2 above. This is the real question I am interested in.
I'm also interested in a broader question. Consider instantiating many
jails this way--say 50 or 100 all hard linked to the same base set of
files. Can we characterize in some general hand-waving way how much
memory (RAM) I would save doing it this way as opposed to the naive way
of 50 or 100 copies of the files? I am assuming that if I have 50 copies
of the files and I run 50 processes in 50 jails, then I will use more
RAM than if I had 50 hard links to the same inode and ran 50 processes
in 50 jails from that one inode. The naive copy method will use more
RAM, but not 50 times more than the hard linking way.
Thank you to any who respond. I hope I'm not completely out to lunch on
this.
Regards,
Paco
--
Consultant, Cigital, Inc.
http://www.cigital.com/
This electronic message transmission contains information that may be
confidential or privileged. The information contained herein is intended
solely for the recipient and use by any other party is not authorized. If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited. If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message. Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Build options for kernel modules
On Fri Mar 21, 2003 at 07:47:42PM +0300, Yar Tikhiy wrote: On Fri, Mar 21, 2003 at 11:25:01AM -0500, The Anarcat wrote: On Fri Mar 21, 2003 at 07:16:58PM +0300, Yar Tikhiy wrote: Yeah, it's all right to compile modules w/o the kernel, but that's not exactly what I was asking about. My question was whether option FOO lines from a kernel configuration file could influence modules. I'm pretty sure they do. A great example is IPFIREWALL_* options: if they don't influence the module, I think we have a problem. ;) My testing a yesterday's CURRENT has shown we did have the problem. Everobody is invited to set options IPFIREWALL_DEFAULT_TO_ACCEPT and to load the resulting ipfw.ko on a remote machine without human access ;-))) [small print: it's a joke, don't actually do that.] Woops. -- Nothing incites to money-crimes like great poverty or great wealth. - Mark Twain pgp0.pgp Description: PGP signature
Re: CerbNG 1.0-RC1 is now avaliable.
On Fri, Mar 21, 2003 at 01:58:38AM +0100, Pawel Jakub Dawidek wrote: [...] Hackers... We have spend a lot of time on coding cerb, so we count and will be very greatful for _any_ opinions, including it suck!. -- Pawel Jakub Dawidek UNIX Systems Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am. pgp0.pgp Description: PGP signature
Re: generalized mergemaster(8)
At 10:15 AM -0800 3/21/03, Tim Kientzle wrote: On Thu Mar 20, 2003, Brandon D. Valentine wrote: I need to recursively merge two directories of source files in which I wish to preserve some original files, install some replacement files outright, and only actually go to the trouble of sdiff(1)ing those files that from the preview udiff look like they are need of a merge. One feature I've long wanted to see in mergemaster is the ability to install an entire directory at a pop, without having to manually inspect every single entry in that directory. A good example is /etc/rc.d/ . I would really like to be told /var/tmp/temproot/etc/rc.d/ and /etc/rc.d/ have 17 differing files. (I)nstall, (D)elete, or (R)ecursively examine? [R] Then I could hit 'I' and update all of /etc/rc.d at once. At times I've asked Doug about some kind of pattern-support in ~/.mergemasterrc, where the user could specify filename-patterns of files where they want the default action to be install instead of leave for later. There are pros and cons with that idea, but that's what I was thinking of for the directories you describe. Doug has suggested that people could maybe do things with the MM_PRE_COMPARE_SCRIPT, for special processing like this. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Lots of kernel core dumps
Hi all!
I'm getting lots of kernel core dumps on my server.
My RAM is OK, I tested it. Below are more detailed informations.
Any help would be greatly appreciated.
I'm not yet intimate with the kernel, but I'm willing to learn it all.
Thanks in advance.
Daniela
--
# uname -a
FreeBSD CM58-27.liwest.at 5.0-RELEASE-p3 FreeBSD 5.0-RELEASE-p3 #4: Sat Mar 1
18:08:27 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CM58-27
i386
# gdb -k kernel.debug vmcore.1
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
panic: bwrite: buffer is not busy???
panic messages:
---
panic: bad pte
syncing disks, buffers remaining... panic: bwrite: buffer is not busy???
Uptime: 4h4m35s
Dumping 511 MB
ata0: resetting devices ..
done
16 32 48[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 64[CTRL-C to
abort] [CTRL-C to abort] [CTRL-C to abort] 80[CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] 96[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] 112 128 144[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort]
[CTRL-C to abort] 160[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort]
[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort]
176[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 192[CTRL-C to
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] 208 224 240 256 272 288 304 320 336 352 368 384 400 416[CTRL-C to
abort] 432 448 464 480 496
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:232
232 dumping++;
(kgdb) where
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:232
#1 0xc033b5e6 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:364
#2 0xc033b833 in panic () at /usr/src/sys/kern/kern_shutdown.c:517
#3 0xc0379fa2 in bwrite (bp=0xce4d4708) at /usr/src/sys/kern/vfs_bio.c:796
#4 0xc037b55e in vfs_bio_awrite (bp=0xce4d4708)
at /usr/src/sys/kern/vfs_bio.c:1643
#5 0xc0307737 in spec_fsync (ap=0xe0d1cb5c)
at /usr/src/sys/fs/specfs/spec_vnops.c:462
#6 0xc0306ca8 in spec_vnoperate (ap=0x0)
at /usr/src/sys/fs/specfs/spec_vnops.c:126
#7 0xc045fb8d in ffs_sync (mp=0xc40cd800, waitfor=2, cred=0xc150ae80,
td=0xc0584000) at vnode_if.h:612
#8 0xc038d01b in sync (td=0xc0584000, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:138
#9 0xc033b25c in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:273
#10 0xc033b833 in panic () at /usr/src/sys/kern/kern_shutdown.c:517
#11 0xc04b7bbb in pmap_remove_pages (pmap=0xc43a33bc, sva=0, eva=3217031168)
at /usr/src/sys/i386/i386/pmap.c:2937
#12 0xc0326572 in exit1 (td=0xc456f9a0, rv=1) at vm_map.h:228
#13 0xc033ed26 in sigexit () at /usr/src/sys/kern/kern_sig.c:1997
#14 0xc033e97a in postsig (sig=1) at /usr/src/sys/kern/kern_sig.c:1886
#15 0xc035b3da in ast (framep=0xe0d1cd48) at /usr/src/sys/kern/subr_trap.c:254
#16 0xc04ac250 in doreti_ast () at {standard input}:446
---Can't read userspace from dump, or kernel process---
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: ld.so and hard links
Paco Hope wrote:
Here's my baseline assumption. If I'm wrong here, I'm only going to get
wronger as I go:
If I have two different programs that both use a shared library,
libfoo.so, the system memory maps the object code they need into the
processes' address spaces. There's only one copy of libfoo.so in memory,
and the two processes each have handles into it (or maybe just to the
pieces of it that they use?).
There's one copy of the code pages. There's one copy of the unmodified
data pages. Everything is mapped COW (copy-on-write). If there are
changes to data pages or a jump table fixup, etc., each process will
gt it's own copy of the modified pages (and *only* the modified pages!).
Step 2 of my question. This gets closer to my real query:
Ok now consider a hard link (not a symlink) from libfoo.so to libbar.so.
One inode, two directory entries. Consider my two programs again, one
linked against libfoo.so and the other linked against libbar.so. When
they run, how many copies of the lib{foo,bar}.so object code are in RAM?
My current hypothesis is 1. Isn't it mmapped off the disk? The inode
matters, not the file name, right? With me so far? Great.
Actually, it's the vnode that matters, not the inode or the file
name. The vnode is used as backing store, through the vnode pager,
for the pages in each process. For each file, there is only one
vnode, and one vmobject_t, corresponding to it. If data or code
pages are modified, as before, since they are COW, what happens is
that each process gets its own pmap entries to copies of the pages,
and those copies are backed using swap as backing store (swap pager).
The reason I make this distinction is that it probably would not
help you to use loopback mounts, which is a problem for you if you
wish to maintain priviledge seperation.
Now consider jail(8). Let's say I have two jail environments (If you
think I mean chroot here, go read jail(8), it's not the same. I'm
assuming folks on hackers know jail.). To make my first jail, I make a
copy of the FreeBSD stuff that my jail needs. To make the second jail, I
create a directory hiearachy, but I *hard link* all the binaries and
libraries and stuff to the same inodes that the first jail uses.
[ ... ]
Now the $64K question: How many instances of, for example, the libz.so.2
object code are in memory? Did my use of jail(8) make any difference? My
intuition is that only one copy of the code is in memory for the same
reason as in step 2 above. This is the real question I am interested in.
If they are hard links, they get the same vnodes. Therefore they
get the same vmobject_t's. Therefore there is a single copy in
memory, until pages are modified, at which point the modified
pages aren't shared, but the rest of the file remains shared.
I'm also interested in a broader question. Consider instantiating many
jails this way--say 50 or 100 all hard linked to the same base set of
files. Can we characterize in some general hand-waving way how much
memory (RAM) I would save doing it this way as opposed to the naive way
of 50 or 100 copies of the files? I am assuming that if I have 50 copies
of the files and I run 50 processes in 50 jails, then I will use more
RAM than if I had 50 hard links to the same inode and ran 50 processes
in 50 jails from that one inode. The naive copy method will use more
RAM, but not 50 times more than the hard linking way.
Thank you to any who respond. I hope I'm not completely out to lunch on
this.
You could potentially save a lot of memory. *However*. You may
not want to do this, since you are defeating priviledge seperation
that is what made you want to use jails in the first place.
Specifically, using your sshd example, say I do this, and then I
end up with 50 or 100 jail instances, which I then use to do
virtual hosting for 50 or 100 different customers.
Now one customer compromises the shared copy of sshd. And can now
log into the jails of all my other customers. In other words, if
you do this, you'd better be very sure that it's read-only media,
or take other precautions.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Lots of kernel core dumps
Daniela wrote: I'm getting lots of kernel core dumps on my server. My RAM is OK, I tested it. Below are more detailed informations. Any help would be greatly appreciated. I'm not yet intimate with the kernel, but I'm willing to learn it all. Thanks in advance. You posted to -hackers, but this is an older version of -current. This is a known problem. I believe it was fixed on the HEAD branch in the last couple of days (i.e. if you update your -current sources, then the problem should be resolved). See recent discussions about trap 12 and panic in NFS, and older discussions about the same panic in smbfs. If you are already running today's -current, you can always try: options DISABLE_PSE options DISABLE_PG_G These are in GENERIC, so if it isn't in your SM58-27 kernel config file, then it's because you went out of your way to take them out. I mention this possibility because of: panic: bad pte -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Lots of kernel core dumps
On Friday 21 March 2003 22:10, Kris Kennaway wrote: On Fri, Mar 21, 2003 at 08:37:46PM +0100, Daniela wrote: Hi all! I'm getting lots of kernel core dumps on my server. My RAM is OK, I tested it. Below are more detailed informations. Any help would be greatly appreciated. I think this was fixed after 5.0-R..upgrade to -current and try again. Kris I'm running 5.0-RELEASE, not -CURRENT. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Lots of kernel core dumps
On Fri, Mar 21, 2003 at 10:26:01PM +0100, Daniela wrote: On Friday 21 March 2003 22:10, Kris Kennaway wrote: On Fri, Mar 21, 2003 at 08:37:46PM +0100, Daniela wrote: Hi all! I'm getting lots of kernel core dumps on my server. My RAM is OK, I tested it. Below are more detailed informations. Any help would be greatly appreciated. I think this was fixed after 5.0-R..upgrade to -current and try again. Kris I'm running 5.0-RELEASE, not -CURRENT. I know, but 5.0-RELEASE was a) A work-in-progress, not a perfect, bug-free release b) A snapshot of 5.0-CURRENT You read the 5.0 Early Adopter's Guide, right? Bugs like this are expected at this stage in the development process, and if you encounter them then you need to either give up on 5.x and go back to 4.x-STABLE, or upgrade to 5.0-CURRENT if they are already fixed there. Kris pgp0.pgp Description: PGP signature
Re: ld.so and hard links
On Sat, 2003-03-22 at 07:30, Terry Lambert wrote: You could potentially save a lot of memory. *However*. You may not want to do this, since you are defeating priviledge seperation that is what made you want to use jails in the first place. There's a Linux Jail like thing called vserver, it has a feature where you hardlink a whole bunch of stuff for different jails (it has tools for building a set of jails from a given tree). It does a copy on write for any of these hardlinked files so you don't get the security issue. No idea if it's possible to implement something like that for a jail :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: misc/41772: can't disable keybell [PATCH]
http://www.freebsd.org/cgi/query-pr.cgi?pr=41772
This appears to be _VERY_ old problem (I don't remember
it on 2.2.7-RELEASE, though)
In short: the beeper still produces noises (clicks) when
shut up with `kbdcontrol -b off`
Finally I got some time to look at
'sys/dev/syscons/syscons.c'. However, I only speak
i386 Asm fluently (no C at all yet), so could
someone plz (fix?) this 3-line 'patch' and commit
it? I'd really like to see it MFC'ed in 4.8-RELEASE
(as well a this one:
'http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/44257' -
it works well for my EIDE controller).
FreeBSD 4.6.2-RELEASE:
===8===
--- ./syscons.c.ORIGFri Mar 21 23:10:05 2003
+++ ./syscons.c Fri Mar 21 23:10:37 2003
@@ -3385,6 +3385,9 @@
if (scp != scp-sc-cur_scp (scp-sc-flags SC_QUIET_BELL))
return;
+if (!(duration pitch))
+ return;
+
if (scp-sc-flags SC_VISUAL_BELL) {
if (scp-sc-blink_in_progress)
return;
===8===
21.03.2003; 23:20:26
[SorAlx] http://cydem.org.ua/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
