Re: deltas for sys/kern/vfs_syscalls.c and sys/kern/vfs_subr.c
--- Bosko Milekic <[EMAIL PROTECTED]> wrote: > On Fri, May 03, 2002 at 10:45:32PM +0100, Hiten Pandya wrote: > > I am submitting a patch which removes the register keyword from > > sys/kern/vfs_syscalls.c. The reason I am doing this is very simple. > > > > The 'register' keyword has no effect, as compilers do enough > optimizations > > on their own. Also, I have seen commits made before which do the same > > thing which I am doing now. I have talked about this patch with > jmallett, > > and various other developers. > > > > This patch is located at: > > http://storm.uk.FreeBSD.org/~hiten/diffs/vfs_syscalls.diff.1 > > Looks good. Cool. Any chance of getting it committed. Note, I also did an md(5) test and both vfs_syscalls.o came out with the same checksum. > > The second issue, is what I am not very sure about, but I had a little > > discussion about this with rwatson. The vfs_subr.c module contains > > a large #if 0'ed section, which basically contains some sysctls. I > > think it has been forgotten for removal, so I am submitting a delta which > > can be used to remove that #if 0'ed section. > > > > Note, I am not very sure about this, that is why I am posting this to > > -hackers. > > > > The patch is located at: > > http://storm.uk.FreeBSD.org/~hiten/diffs/vfs_subr.c.diff.1 > > I don't think that removing the code is a problem. The real person to > ask would be dillon, since he was the one who placed the #if 0 around > the block. Matt, what do you think about it; do you think that there is chance of removing that section of code? It has been lying there for ages. If you think it can be removed, I will be greatful if you can commit my delta for it. Regards, -- Hiten __ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: naive i386 && FreeBSD interrupt question
On Fri, 3 May 2002, Michael Smith wrote: > > > > This was -stable- but it's really a hacker's question. > > > > I really am *not* much of an i386 weenie and I'll have to admit that I don't > > fully understand the interrupt mask scheme and I ran into a troubling problem > > . > > > > I was running some very extensive tests on a dual processor (but not SMP > > configured) system- I was in the middle of calling busdma_load from the isp > > driver when I got interrupted and blew up fielding an isp interrupt. > > You call isp_intr out of isp_watchdog; any chance that the timeout could > have gone off and dumped you in there? The callstack didn't show isp_watchdog- it also calls splcam() > > Otherwise, no, you should not have had your interrupt handler reentered > while it was masked. You shouldn't have to call splsoftvm() when calling > the busdma code; it should take whatever locks it needs at the time. > > Knowing the contents of cpl vs. the CAM spl mask and the actual interrupt > in question would be useful, as would the stack backtrace from the > explosion (ie. when you say "got interrupted" was the backtrace through > the actual interrupt entry point?) > Yes- that's the problematic thingie. I haven't reproduced it yet and didn't save the stack, but basically it was in the middle of call to the budma code when isp_intr was executed. If I see it again, I'll stay in DDB and spend more time. This was at a client's lab and running maybe 5000+ interrupts/sec pumping stuff thru Fibre Channel. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: deltas for sys/kern/vfs_syscalls.c and sys/kern/vfs_subr.c
:> > Note, I am not very sure about this, that is why I am posting this to :> > -hackers. :> > :> > The patch is located at: :> > http://storm.uk.FreeBSD.org/~hiten/diffs/vfs_subr.c.diff.1 :> :> I don't think that removing the code is a problem. The real person to :> ask would be dillon, since he was the one who placed the #if 0 around :> the block. : :Matt, what do you think about it; do you think that there is chance of :removing that section of code? It has been lying there for ages. If you :think it can be removed, I will be greatful if you can commit my delta for :it. : :Regards, : : -- Hiten Yes, the code can be safely removed. I #if 0'd it out last October when I redid the vnode recycling code. We're not going to be going back to the old way of doing things so this code is definitely obsolete and can be removed. I will remove it now. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
50% off sale + additional 30% off at Frederick's!
Title: Frederick's of Hollywood This email is not sent unsolicited. This is an Opt-In Network mailing! This message is sent to subscribers ONLY. The e-mail subscription address is: [EMAIL PROTECTED] To unsubscribe please click here. or Send an email with the word 'remove' in the subject line to [EMAIL PROTECTED] Or you may mail us at: PO BOX 810052 Boca Raton, Fl 33481-0052 B0D5451A-A4D4-4169-8F97-8AE3C4E57278
using cvsup to put the same collection in two places
The objective: I want the same collection in two different places, but I want to use two different refuse files. Some parts of the collection I don't want in one location. The background: I'm playing with phpAdsNew. I've just imported it into my cvs tree for my website. I use https to administer the site. As such, I'd prefer not to have the phpAdsNew/admin/ directory in the public section of the website. I'd like to be able to cvsup phpAdsNew to my website into two different locations (this I can do already) and have a refuse file for one and not for the other (this is where I'm failing). What I've tried: At present I have these two supfiles: This puts the collection in the https section of the website: less ~/phpAdsAdmin-supfile *default host=localhost *default base=/home/freebsddiary/admin *default release=cvs tag=. *default delete use-rel-suffix *default umask=007 *default preserve fbsd-phpAds This puts the collection in the http section of the website: $ less ~/phpAds-supfile *default host=localhost *default base=/home/freebsddiary *default release=cvs tag=. *default delete use-rel-suffix *default umask=007 *default preserve fbsd-phpAds Normally a refuse file would go into /home/freebsddiary/sup/ where col is the name of the collection (in this case it's fbsd-phpAds). With the above setup I can have only one refuse file. I need two. So I tried creating a second collection (fbsd-phpAdsAdmin) which merely pointed at the original collection. Sadly, this didn't create a /home/freebsddiary/sup/phpAdsAdmin as I hoped. Any clues? Thanks. -- Dan Langille The FreeBSD Diary - http://freebsddiary.org/ - practical examples To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Request for submissions: FreeBSD Bi-Monthly Development Status Report
This is a solicitation for submissions for the February 2002 - April 2002 FreeBSD Bi-Monthly Development Status Report. All submissions are due by May 10, 2002. Submissions should be made by filling out the template found at: http://www.FreeBSD.org/news/status/report-sample.xml Submissions must then be e-mailed to the following address: [EMAIL PROTECTED] For automatic processing. Reports must be submitted in the XML format described, or they will be silently dropped. Submissions made to other e-mail addresses will be ignored. Status reports should be submitted once per project, although project developers may choose to submit additional reports on specific sub-projects of substantial size. Status reports are typically one or two short paragraphs, but the text may be up to 20 lines in length. Submissions are welcome on a variety of topics relating to FreeBSD, including development, documentation, advocacy, and development processes. Prior status reports may be viewed at: http://www.FreeBSD.org/news/status/ (Yes, I'm aware that February through April is three months, not two months, but for personal reasons, I was unavailable to solicit reports at the end of March. Please go ahead and cover the three-month period, and ignore the fact that the report is entitled bi-monthly, that's because this is a form letter.) Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: bug in pw, freebsd 4.5
On Thu, May 02, 2002 at 03:38:47PM -0700 I heard the voice of Jeff Jirsa, and lo! it spake thus: > > Feel free to correct me if I'm wrong, but /var/run seems like the more > logical answer. Read-only / filesystems would have a hard time creating > temp lock files in /etc. If nothing else, make it something that's > easily configurable to avoid problems with read only filesystems. Well, read-only / filesystems would have a hard time creating /etc/master.passwd.new in the middle of pw's actions, too :) /var/run isn't a perfect choice, but it doesn't seem a bad one, and there's rather a bit of precedent for using it for state files, which I'd call a lock file (PID files, Apache stores some state, log/named sockets, etc). -- Matthew Fuller (MF4839) |[EMAIL PROTECTED] Unix Systems Administrator |[EMAIL PROTECTED] Specializing in FreeBSD |http://www.over-yonder.net/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
