Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers
On Sun, 20 Nov 2011, Kostik Belousov wrote: On Sun, Nov 20, 2011 at 12:40:42PM +0100, Robert Millan wrote: On Sat, Nov 19, 2011 at 07:56:20PM +0200, Kostik Belousov wrote: I fully agree with an idea that compiler is not an authorative source of the knowledge of the FreeBSD version. Even more, I argue that we shall not rely on compiler for this at all. Ideally, we should be able to build FreeBSD using the stock compilers without local modifications. Thus relying on the symbols defined by compiler, and not the source is the thing to avoid and consistently remove. We must do this to be able to use third-party tooldchain for FreeBSD builds. That said, why not define __FreeBSD_kernel as equal to __FreeBSD_version ? And then make more strong wording about other systems that use the macro, e.g. remove 'may' from the kFreeBSD example. Also, please remove the smile from comment. Ok. New patch attached. And the last, question, why not do #ifndef __FreeBSD_kernel__ #define __FreeBSD_kernel__ __FreeBSD_version #endif ? #undef is too big tools tool apply there, IMO. #ifndef is too big to apply here, IMO :-). __FreeBSD_kernel__ is in the implementation namespace, so any previous definition of it is a bug. The #ifndef breaks the warning for this bug. And why not use FreeBSD style? In KNF, the fields are separated by tabs, not spaces. In FreeBSD style, trailing underscores are not used for names in the implementation namespace, since they have no effect on namespaces. The name __FreeBSD_version is an example of this. Does existing practice require using the name with the trailing underscores? Bruce ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
The FreeBSD Project in the Google Code-In 2011 contest
Hello, (cross-posted message; please keep eventual comments on freebsd-hackers@) The FreeBSD project has been accepted to the Google Code-In 2011 contest. http://google-opensource.blogspot.com/2011/11/google-code-in-2011-participating.html We have proposed 50 tasks so far, and more are still coming! This is an event similar to the Google Summer of Code, but is targetted to people in the 13-17 age range. Young people will be working on FreeBSD-related tasks for the next weeks. If you know any potential candidates, feel free to forward this message. Brief summary: T-shirts and possibility of earning some $$$ for participants. The best participants get a chance to see the Google complex in Mountain View, Silicon Valley, California, USA. FreeBSD tasks are here: http://wiki.freebsd.org/GoogleCodeIn/2011 Ideas page can be extended till December, 16th! Contest's home page: http://www.google-melange.com/gci/homepage/google/gci2011 After you create an account, you can acquire tasks which you're interested in (if any of them are left!) Start date: November, 21st (tomorrow) Official communication channels: IRC (EFNet):#freebsd-soc Q/A:wkos...@freebsd.org, jc...@freebsd.org, ead...@freebsd.org wkoszek, jceel, eadler on IRC Mailing list: freebsd-hackers@ Please coordinate communication with your mentor. Include '[GCIN]' header when posting to freebsd-hackers@ In case of potential task candidates, ideas and suggestions, feel free to contact me. -- Wojciech A. Koszek wkos...@freebsd.czest.pl http://FreeBSD.czest.pl/~wkoszek/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Adding disk firmware programming capability to camcontrol
On Sun, Nov 20, 2011 at 7:44 AM, Pegasus Mc Cleaft wrote: > On Sunday 20 November 2011 15:24:41 Andriy Gapon wrote: >> > I have tried issuing a TUR to all my drives to see if it was controller >> > or drive specific, but all of them return the same error (The drives are >> > Seagate, Hitachi and WD). >> > >> > What am I doing wrong? >> >> You are sending SCSI commands to a (S)ATA drive. > > Ah... Bummer... I thought that might be the issue. > > I had kind of hoped that the code would also handle the ATA drives as well, > but still this will be a great feature to have in camcontrol as it is. Enhancements will need to be added to pass through the right commands from CAM_ATA to the ata layer. Cheers, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ee (easy editor) bugged on 9.0?
Am 20.11.2011 um 14:41 schrieb Jason Edwards: > Some of you asked for the environmental settings. Using 'env' the > output begins with: > > -- on console -- > TERM=cons25 > SHELL=/usr/local/bin/bash > > -- via SSH -- > TERM=xterm > SHELL=/usr/local/bin/bash > > Via SSH the ee editor works as it should. On the console it is bugged. As I suspected. On my fresh 90-RC1 install, I get xterm for all the console terminals. You'll have to check where your /etc/ttys picks up the old entries. Both stable and releng have the updated version, as far as I can tell. If your /etc/ttys has ttyv0 "/usr/libexec/getty Pc" xterm on secure and so on, you'll need to check whether a login script resets the TERM environment variable. Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ee (easy editor) bugged on 9.0?
On Sun Nov 20 11, Jason Edwards wrote: > On Sat, Nov 19, 2011 at 6:07 PM, Stefan Bethke wrote: > > Am 19.11.2011 um 17:29 schrieb Jason Edwards: > > > >> Dear list, > >> > >> Has anyone noticed the easy editor is quite bugged on 9.0? On console > >> direct access, opening the easy editor has several bugs: > >> > >> 1) the cursor starts on line 2 instead of line 1 > >> 2) the line numbering is printed on line 1 instead of the boundary (line 0) > >> 3) the keys page up and page down bring the escape menu > >> > >> Strange enough, if I SSH into the box the ee editor works normally. So > >> I'm wondering if this is something other people have noticed? Just > >> want to exclude the possibility of me doing something wrong. > >> > >> I've noticed this behavior on 9-CURRENT, 9.0-RC1 as well as 9.0-RC2, > >> amd64. GENERIC kernel and tested inside Virtualbox. > > > > Working fine here on 9.0-RC1. > > > > Is this a fresh install, or did you upgrade? Have you updated your ttys to > > set the terminal type to xterm instead of cons25? > > > This is a fresh install. I do make a LiveCD using scripted tools. But > it pretty much is a vanilla FreeBSD install with just some packages > preinstalled (webserver, php, etc). The only relevant changes I think > are a change to /etc/ttys. But when I revert the file back to the > defaults, the problem stays. I thought that perhaps Virtualbox had > something to do with it, but it seems to happen on a real system as > well. > > Some of you asked for the environmental settings. Using 'env' the > output begins with: > > -- on console -- > TERM=cons25 > SHELL=/usr/local/bin/bash > > -- via SSH -- > TERM=xterm > SHELL=/usr/local/bin/bash > > Via SSH the ee editor works as it should. On the console it is bugged. i just grabbed a copy of "FreeBSD-9.0-RC2-amd64-dvd1.iso" and ran it in qemu. i noticed nothing irregular running ee. also TERM is set to "xterm" on the console. so this is either an issue with bash (have you tried running sh?) or something in your /etc is broken. cheers. alex > > Regards, > Jason ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]
2011/11/20 Kostik Belousov : > On Sun, Nov 20, 2011 at 08:22:38PM +0100, Attilio Rao wrote: >> 2011/11/20 Kostik Belousov : >> > On Sun, Nov 20, 2011 at 08:04:21PM +0100, Attilio Rao wrote: >> >> This other patch converts sx to a similar interface which cleans up >> >> vm_map.c: >> >> http://www.freebsd.org/~attilio/sxfileline.patch >> >> >> >> What do you think about it? >> > >> > This one only changes the KBI ? Note that _sx suffix is not reserved. >> >> In which sense? >> If you want to keep the shim support for KLD (thus the hard path) you >> will always need to keep an hard function and thus you still need a >> macro acting as a gate between the 'hard function' (or KLD version, if >> you prefer) and the fast case, that is where the "_" suffix came from. > > As I see, right now kernel exports e.g. _sx_try_slock() for the hard path. > After the patch, it will export sx_try_slock_() for the same purpose. > The old modules, which call _sx_try_slock(), cannot be loaded into > the patched kernel. Am I reading the patch wrong ? We shouldn't be concerned about it for -CURRENT, when MFCing this patch I'll just make: #define sx_try_slock_ _sx_try_slock rather than renaming the function. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]
On Sun, Nov 20, 2011 at 08:22:38PM +0100, Attilio Rao wrote: > 2011/11/20 Kostik Belousov : > > On Sun, Nov 20, 2011 at 08:04:21PM +0100, Attilio Rao wrote: > >> This other patch converts sx to a similar interface which cleans up > >> vm_map.c: > >> http://www.freebsd.org/~attilio/sxfileline.patch > >> > >> What do you think about it? > > > > This one only changes the KBI ? Note that _sx suffix is not reserved. > > In which sense? > If you want to keep the shim support for KLD (thus the hard path) you > will always need to keep an hard function and thus you still need a > macro acting as a gate between the 'hard function' (or KLD version, if > you prefer) and the fast case, that is where the "_" suffix came from. As I see, right now kernel exports e.g. _sx_try_slock() for the hard path. After the patch, it will export sx_try_slock_() for the same purpose. The old modules, which call _sx_try_slock(), cannot be loaded into the patched kernel. Am I reading the patch wrong ? pgperrxtbJjmU.pgp Description: PGP signature
Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]
2011/11/20 Kostik Belousov : > On Sun, Nov 20, 2011 at 08:04:21PM +0100, Attilio Rao wrote: >> This other patch converts sx to a similar interface which cleans up vm_map.c: >> http://www.freebsd.org/~attilio/sxfileline.patch >> >> What do you think about it? > > This one only changes the KBI ? Note that _sx suffix is not reserved. In which sense? If you want to keep the shim support for KLD (thus the hard path) you will always need to keep an hard function and thus you still need a macro acting as a gate between the 'hard function' (or KLD version, if you prefer) and the fast case, that is where the "_" suffix came from. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]
On Sun, Nov 20, 2011 at 08:04:21PM +0100, Attilio Rao wrote: > This other patch converts sx to a similar interface which cleans up vm_map.c: > http://www.freebsd.org/~attilio/sxfileline.patch > > What do you think about it? This one only changes the KBI ? Note that _sx suffix is not reserved. pgpCdjEU3nGge.pgp Description: PGP signature
Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]
2011/11/20 Attilio Rao : > 2011/11/18 Attilio Rao : >> 2011/11/18 Attilio Rao : >>> 2011/11/18 Kostik Belousov : On Fri, Nov 18, 2011 at 11:40:28AM +0100, Attilio Rao wrote: > 2011/11/16 Kostik Belousov : > > On Tue, Nov 15, 2011 at 07:15:01PM +0100, Attilio Rao wrote: > >> 2011/11/7 Kostik Belousov : > >> > On Mon, Nov 07, 2011 at 11:45:38AM -0600, Alan Cox wrote: > >> >> Ok. I'll offer one final suggestion. Please consider an > >> >> alternative > >> >> suffix to "func". Perhaps, "kbi" or "KBI". In other words, > >> >> something > >> >> that hints at the function's reason for existing. > >> > > >> > Sure. Below is the extraction of only vm_page_lock() bits, together > >> > with the suggested rename. When Attilio provides the promised > >> > simplification > >> > of the mutex KPI, this can be reduced. > >> > >> My tentative patch is here: > >> http://www.freebsd.org/~attilio/mutexfileline.patch > >> > >> I need to make more compile testing later, but it already compiles > >> GENERIC + modules fine on HEAD. > >> > >> The patch provides a common entrypoint, option independent, for both > >> fast case and debug/compat case. > >> Additively, it almost entirely fixes the standard violation of the > >> reserved namespace, as you described (the notable exception being the > >> macro used in the fast path, that I want to fix as well, but in a > >> separate commit). > >> > >> Now the file/line couplet can be passed to the "_" suffix variant of > >> the flag functions. > > Yes, this is exactly KPI that I would use when available for the > > vm_page_lock() patch. > > > >> > >> eadler@ reviewed the mutex.h comment. > >> > >> Please let me know what you think about it, as long as we agree on the > >> patch I'll commit it. > > But I also agree with John that imposing large churn due to the > > elimination > > of the '__' prefix is too late now. At least it will make the change > > non-MFCable. Besides, we already lived with the names for 10+ years. > > > > I will be happy to have the part of the patch that exports the > > mtx_XXX_(mtx, > > file, line) defines which can be used without taking care of LOCK_DEBUG > > or MUTEX_NOINLINE in the consumer code. > > Ok, this patch should just add the compat stub: > http://www.freebsd.org/~attilio/mutexfileline2.patch Am I right that I would use mtx_lock_(mtx, file, line) etc ? If yes, I am fine with it. >>> >>> Yes that is correct. >>> >>> However, I'm a bit confused on one aspect: would you mind using >>> _mtx_lock_flags() instead? >>> If you don't mind the "underscore namespace violation" I think I can >>> make a much smaller patch against HEAD for it. >>> >>> Otherwise, the one now posted should be ok. >> >> After thinking more about it, I think that is basically the shorter >> version I can came up with. >> >> Please consider: >> http://www.freebsd.org/~attilio/mutexfileline2.patch > > This is now committed as r227758,227759, you can update your patch now. This other patch converts sx to a similar interface which cleans up vm_map.c: http://www.freebsd.org/~attilio/sxfileline.patch What do you think about it? Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Acer Aspire Atheros Netbook
hail, I just installed 9.0 RC2 in Aspire One 751h and the atheros shows in ifconfig: ath0: flags=8843 metric 0 mtu 2290 ether xx:xx:xx:xx:xx:xx nd6 options=29 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated wlan0: flags=8843 metric 0 mtu 1500 ether xx:xx:xx:xx:xx:xx nd6 options=29 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid "" channel 9 (2452 MHz 11g) regdomain 101 indoor ecm authmode WPA1+WPA2/802.11i privacy OFF txpower 20 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme burst but is unusable. I found this: http://markmail.org/message/rhv2s2n7jwf6dj4w and in fact I can't use it. Is there any news ? anyone using this card ? anything I could do ? thanks, matheus -- Pregando o ódio a Oi desde 2007 We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]
It looks good to me.
Attilio
2011/11/20 Kostik Belousov :
> On Sun, Nov 20, 2011 at 07:02:14PM +0100, Attilio Rao wrote:
>> 2011/11/20 Kostik Belousov :
>> > +#define vm_page_lock_assert(m, a) \
>> > + vm_page_lock_assert_KBI((m), (a), LOCK_FILE, LOCK_LINE)
>>
>> I think you should put the "\" in the last tab and also, for
>> consistency, you may want to use __FILE__ and __LINE__ for assert (or
>> maybe I should also switch mutex.h to use LOCK_FILE and LOCK_LINE at
>> some point?).
> I never saw the requirement for the backslash. I am consistent with
> PA_UNLOCK_COND() several lines above.
>
> Changed assert to use __FILE/LINE__.
>
>>
>> > +#else
>> > +#define vm_page_lock_assert(m, a)
>> > +#endif
>> > +#else /* KLD_MODULE */
>>
>> This should be /* !KLD_MODULE */, I guess?
> Changed.
>
>>
>> > #define vm_page_lockptr(m)
>>
>> This is not defined for the KLD_MODULE case?
> Yes, explicitely. This was discussed.
> http://lists.freebsd.org/pipermail/freebsd-current/2011-November/029009.html
>
> diff --git a/sys/vm/vm_page.c b/sys/vm/vm_page.c
> index d592ac0..74e5126 100644
> --- a/sys/vm/vm_page.c
> +++ b/sys/vm/vm_page.c
> @@ -2843,6 +2843,34 @@ vm_page_test_dirty(vm_page_t m)
> vm_page_dirty(m);
> }
>
> +void
> +vm_page_lock_KBI(vm_page_t m, const char *file, int line)
> +{
> +
> + mtx_lock_flags_(vm_page_lockptr(m), 0, file, line);
> +}
> +
> +void
> +vm_page_unlock_KBI(vm_page_t m, const char *file, int line)
> +{
> +
> + mtx_unlock_flags_(vm_page_lockptr(m), 0, file, line);
> +}
> +
> +int
> +vm_page_trylock_KBI(vm_page_t m, const char *file, int line)
> +{
> +
> + return (mtx_trylock_flags_(vm_page_lockptr(m), 0, file, line));
> +}
> +
> +void
> +vm_page_lock_assert_KBI(vm_page_t m, int a, const char *file, int line)
> +{
> +
> + mtx_assert_(vm_page_lockptr(m), a, file, line);
> +}
> +
> int so_zerocp_fullpage = 0;
>
> /*
> diff --git a/sys/vm/vm_page.h b/sys/vm/vm_page.h
> index 151710d..1fab735 100644
> --- a/sys/vm/vm_page.h
> +++ b/sys/vm/vm_page.h
> @@ -218,11 +218,23 @@ extern struct vpglocks pa_lock[];
>
> #define PA_LOCK_ASSERT(pa, a) mtx_assert(PA_LOCKPTR(pa), (a))
>
> +#ifdef KLD_MODULE
> +#define vm_page_lock(m) vm_page_lock_KBI((m), LOCK_FILE,
> LOCK_LINE)
> +#define vm_page_unlock(m) vm_page_unlock_KBI((m), LOCK_FILE,
> LOCK_LINE)
> +#define vm_page_trylock(m) vm_page_trylock_KBI((m), LOCK_FILE,
> LOCK_LINE)
> +#ifdef INVARIANTS
> +#define vm_page_lock_assert(m, a) \
> + vm_page_lock_assert_KBI((m), (a), __FILE__, __LINE__)
> +#else
> +#define vm_page_lock_assert(m, a)
> +#endif
> +#else /* !KLD_MODULE */
> #define vm_page_lockptr(m) (PA_LOCKPTR(VM_PAGE_TO_PHYS((m
> #define vm_page_lock(m) mtx_lock(vm_page_lockptr((m)))
> #define vm_page_unlock(m) mtx_unlock(vm_page_lockptr((m)))
> #define vm_page_trylock(m) mtx_trylock(vm_page_lockptr((m)))
> #define vm_page_lock_assert(m, a)
> mtx_assert(vm_page_lockptr((m)), (a))
> +#endif
>
> #define vm_page_queue_free_mtx vm_page_queue_free_lock.data
> /*
> @@ -405,6 +417,11 @@ void vm_page_cowfault (vm_page_t);
> int vm_page_cowsetup(vm_page_t);
> void vm_page_cowclear (vm_page_t);
>
> +void vm_page_lock_KBI(vm_page_t m, const char *file, int line);
> +void vm_page_unlock_KBI(vm_page_t m, const char *file, int line);
> +int vm_page_trylock_KBI(vm_page_t m, const char *file, int line);
> +void vm_page_lock_assert_KBI(vm_page_t m, int a, const char *file, int line);
> +
> #ifdef INVARIANTS
> void vm_page_object_lock_assert(vm_page_t m);
> #define VM_PAGE_OBJECT_LOCK_ASSERT(m) vm_page_object_lock_assert(m)
>
--
Peace can only be achieved by understanding - A. Einstein
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]
On Sun, Nov 20, 2011 at 07:02:14PM +0100, Attilio Rao wrote:
> 2011/11/20 Kostik Belousov :
> > +#define vm_page_lock_assert(m, a) \
> > + vm_page_lock_assert_KBI((m), (a), LOCK_FILE, LOCK_LINE)
>
> I think you should put the "\" in the last tab and also, for
> consistency, you may want to use __FILE__ and __LINE__ for assert (or
> maybe I should also switch mutex.h to use LOCK_FILE and LOCK_LINE at
> some point?).
I never saw the requirement for the backslash. I am consistent with
PA_UNLOCK_COND() several lines above.
Changed assert to use __FILE/LINE__.
>
> > +#else
> > +#define vm_page_lock_assert(m, a)
> > +#endif
> > +#else /* KLD_MODULE */
>
> This should be /* !KLD_MODULE */, I guess?
Changed.
>
> > #define vm_page_lockptr(m)
>
> This is not defined for the KLD_MODULE case?
Yes, explicitely. This was discussed.
http://lists.freebsd.org/pipermail/freebsd-current/2011-November/029009.html
diff --git a/sys/vm/vm_page.c b/sys/vm/vm_page.c
index d592ac0..74e5126 100644
--- a/sys/vm/vm_page.c
+++ b/sys/vm/vm_page.c
@@ -2843,6 +2843,34 @@ vm_page_test_dirty(vm_page_t m)
vm_page_dirty(m);
}
+void
+vm_page_lock_KBI(vm_page_t m, const char *file, int line)
+{
+
+ mtx_lock_flags_(vm_page_lockptr(m), 0, file, line);
+}
+
+void
+vm_page_unlock_KBI(vm_page_t m, const char *file, int line)
+{
+
+ mtx_unlock_flags_(vm_page_lockptr(m), 0, file, line);
+}
+
+int
+vm_page_trylock_KBI(vm_page_t m, const char *file, int line)
+{
+
+ return (mtx_trylock_flags_(vm_page_lockptr(m), 0, file, line));
+}
+
+void
+vm_page_lock_assert_KBI(vm_page_t m, int a, const char *file, int line)
+{
+
+ mtx_assert_(vm_page_lockptr(m), a, file, line);
+}
+
int so_zerocp_fullpage = 0;
/*
diff --git a/sys/vm/vm_page.h b/sys/vm/vm_page.h
index 151710d..1fab735 100644
--- a/sys/vm/vm_page.h
+++ b/sys/vm/vm_page.h
@@ -218,11 +218,23 @@ extern struct vpglocks pa_lock[];
#definePA_LOCK_ASSERT(pa, a) mtx_assert(PA_LOCKPTR(pa), (a))
+#ifdef KLD_MODULE
+#definevm_page_lock(m) vm_page_lock_KBI((m), LOCK_FILE,
LOCK_LINE)
+#definevm_page_unlock(m) vm_page_unlock_KBI((m), LOCK_FILE,
LOCK_LINE)
+#definevm_page_trylock(m) vm_page_trylock_KBI((m), LOCK_FILE,
LOCK_LINE)
+#ifdef INVARIANTS
+#definevm_page_lock_assert(m, a) \
+vm_page_lock_assert_KBI((m), (a), __FILE__, __LINE__)
+#else
+#definevm_page_lock_assert(m, a)
+#endif
+#else /* !KLD_MODULE */
#definevm_page_lockptr(m) (PA_LOCKPTR(VM_PAGE_TO_PHYS((m
#definevm_page_lock(m) mtx_lock(vm_page_lockptr((m)))
#definevm_page_unlock(m) mtx_unlock(vm_page_lockptr((m)))
#definevm_page_trylock(m) mtx_trylock(vm_page_lockptr((m)))
#definevm_page_lock_assert(m, a)
mtx_assert(vm_page_lockptr((m)), (a))
+#endif
#definevm_page_queue_free_mtx vm_page_queue_free_lock.data
/*
@@ -405,6 +417,11 @@ void vm_page_cowfault (vm_page_t);
int vm_page_cowsetup(vm_page_t);
void vm_page_cowclear (vm_page_t);
+void vm_page_lock_KBI(vm_page_t m, const char *file, int line);
+void vm_page_unlock_KBI(vm_page_t m, const char *file, int line);
+int vm_page_trylock_KBI(vm_page_t m, const char *file, int line);
+void vm_page_lock_assert_KBI(vm_page_t m, int a, const char *file, int line);
+
#ifdef INVARIANTS
void vm_page_object_lock_assert(vm_page_t m);
#defineVM_PAGE_OBJECT_LOCK_ASSERT(m) vm_page_object_lock_assert(m)
pgpRqyzyLnGBT.pgp
Description: PGP signature
Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]
2011/11/20 Kostik Belousov :
> On Sun, Nov 20, 2011 at 05:37:33PM +0100, Attilio Rao wrote:
>> 2011/11/18 Attilio Rao :
>> > Please consider:
>> > http://www.freebsd.org/~attilio/mutexfileline2.patch
>>
>> This is now committed as r227758,227759, you can update your patch now.
> Here is it.
>
> diff --git a/sys/vm/vm_page.c b/sys/vm/vm_page.c
> index d592ac0..74e5126 100644
> --- a/sys/vm/vm_page.c
> +++ b/sys/vm/vm_page.c
> @@ -2843,6 +2843,34 @@ vm_page_test_dirty(vm_page_t m)
> vm_page_dirty(m);
> }
>
> +void
> +vm_page_lock_KBI(vm_page_t m, const char *file, int line)
> +{
> +
> + mtx_lock_flags_(vm_page_lockptr(m), 0, file, line);
> +}
> +
> +void
> +vm_page_unlock_KBI(vm_page_t m, const char *file, int line)
> +{
> +
> + mtx_unlock_flags_(vm_page_lockptr(m), 0, file, line);
> +}
> +
> +int
> +vm_page_trylock_KBI(vm_page_t m, const char *file, int line)
> +{
> +
> + return (mtx_trylock_flags_(vm_page_lockptr(m), 0, file, line));
> +}
> +
> +void
> +vm_page_lock_assert_KBI(vm_page_t m, int a, const char *file, int line)
> +{
> +
> + mtx_assert_(vm_page_lockptr(m), a, file, line);
> +}
> +
> int so_zerocp_fullpage = 0;
>
> /*
> diff --git a/sys/vm/vm_page.h b/sys/vm/vm_page.h
> index 151710d..fe0295b 100644
> --- a/sys/vm/vm_page.h
> +++ b/sys/vm/vm_page.h
> @@ -218,11 +218,23 @@ extern struct vpglocks pa_lock[];
>
> #define PA_LOCK_ASSERT(pa, a) mtx_assert(PA_LOCKPTR(pa), (a))
>
> +#ifdef KLD_MODULE
> +#define vm_page_lock(m) vm_page_lock_KBI((m), LOCK_FILE,
> LOCK_LINE)
> +#define vm_page_unlock(m) vm_page_unlock_KBI((m), LOCK_FILE,
> LOCK_LINE)
> +#define vm_page_trylock(m) vm_page_trylock_KBI((m), LOCK_FILE,
> LOCK_LINE)
> +#ifdef INVARIANTS
> +#define vm_page_lock_assert(m, a) \
> + vm_page_lock_assert_KBI((m), (a), LOCK_FILE, LOCK_LINE)
I think you should put the "\" in the last tab and also, for
consistency, you may want to use __FILE__ and __LINE__ for assert (or
maybe I should also switch mutex.h to use LOCK_FILE and LOCK_LINE at
some point?).
> +#else
> +#define vm_page_lock_assert(m, a)
> +#endif
> +#else /* KLD_MODULE */
This should be /* !KLD_MODULE */, I guess?
> #define vm_page_lockptr(m)
This is not defined for the KLD_MODULE case?
Attilio
--
Peace can only be achieved by understanding - A. Einstein
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers
On Sun, Nov 20, 2011 at 12:40:42PM +0100, Robert Millan wrote: > On Sat, Nov 19, 2011 at 07:56:20PM +0200, Kostik Belousov wrote: > > I fully agree with an idea that compiler is not an authorative source > > of the knowledge of the FreeBSD version. Even more, I argue that we shall > > not rely on compiler for this at all. Ideally, we should be able to > > build FreeBSD using the stock compilers without local modifications. > > Thus relying on the symbols defined by compiler, and not the source > > is the thing to avoid and consistently remove. > > > > We must do this to be able to use third-party tooldchain for FreeBSD builds. > > > > That said, why not define __FreeBSD_kernel as equal to __FreeBSD_version ? > > And then make more strong wording about other systems that use the macro, > > e.g. remove 'may' from the kFreeBSD example. > > Also, please remove the smile from comment. > > Ok. New patch attached. And the last, question, why not do #ifndef __FreeBSD_kernel__ #define __FreeBSD_kernel__ __FreeBSD_version #endif ? #undef is too big tools tool apply there, IMO. pgp1sbRkFtD8N.pgp Description: PGP signature
Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]
On Sun, Nov 20, 2011 at 05:37:33PM +0100, Attilio Rao wrote:
> 2011/11/18 Attilio Rao :
> > Please consider:
> > http://www.freebsd.org/~attilio/mutexfileline2.patch
>
> This is now committed as r227758,227759, you can update your patch now.
Here is it.
diff --git a/sys/vm/vm_page.c b/sys/vm/vm_page.c
index d592ac0..74e5126 100644
--- a/sys/vm/vm_page.c
+++ b/sys/vm/vm_page.c
@@ -2843,6 +2843,34 @@ vm_page_test_dirty(vm_page_t m)
vm_page_dirty(m);
}
+void
+vm_page_lock_KBI(vm_page_t m, const char *file, int line)
+{
+
+ mtx_lock_flags_(vm_page_lockptr(m), 0, file, line);
+}
+
+void
+vm_page_unlock_KBI(vm_page_t m, const char *file, int line)
+{
+
+ mtx_unlock_flags_(vm_page_lockptr(m), 0, file, line);
+}
+
+int
+vm_page_trylock_KBI(vm_page_t m, const char *file, int line)
+{
+
+ return (mtx_trylock_flags_(vm_page_lockptr(m), 0, file, line));
+}
+
+void
+vm_page_lock_assert_KBI(vm_page_t m, int a, const char *file, int line)
+{
+
+ mtx_assert_(vm_page_lockptr(m), a, file, line);
+}
+
int so_zerocp_fullpage = 0;
/*
diff --git a/sys/vm/vm_page.h b/sys/vm/vm_page.h
index 151710d..fe0295b 100644
--- a/sys/vm/vm_page.h
+++ b/sys/vm/vm_page.h
@@ -218,11 +218,23 @@ extern struct vpglocks pa_lock[];
#definePA_LOCK_ASSERT(pa, a) mtx_assert(PA_LOCKPTR(pa), (a))
+#ifdef KLD_MODULE
+#definevm_page_lock(m) vm_page_lock_KBI((m), LOCK_FILE,
LOCK_LINE)
+#definevm_page_unlock(m) vm_page_unlock_KBI((m), LOCK_FILE,
LOCK_LINE)
+#definevm_page_trylock(m) vm_page_trylock_KBI((m), LOCK_FILE,
LOCK_LINE)
+#ifdef INVARIANTS
+#definevm_page_lock_assert(m, a) \
+vm_page_lock_assert_KBI((m), (a), LOCK_FILE, LOCK_LINE)
+#else
+#definevm_page_lock_assert(m, a)
+#endif
+#else /* KLD_MODULE */
#definevm_page_lockptr(m) (PA_LOCKPTR(VM_PAGE_TO_PHYS((m
#definevm_page_lock(m) mtx_lock(vm_page_lockptr((m)))
#definevm_page_unlock(m) mtx_unlock(vm_page_lockptr((m)))
#definevm_page_trylock(m) mtx_trylock(vm_page_lockptr((m)))
#definevm_page_lock_assert(m, a)
mtx_assert(vm_page_lockptr((m)), (a))
+#endif
#definevm_page_queue_free_mtx vm_page_queue_free_lock.data
/*
@@ -405,6 +417,11 @@ void vm_page_cowfault (vm_page_t);
int vm_page_cowsetup(vm_page_t);
void vm_page_cowclear (vm_page_t);
+void vm_page_lock_KBI(vm_page_t m, const char *file, int line);
+void vm_page_unlock_KBI(vm_page_t m, const char *file, int line);
+int vm_page_trylock_KBI(vm_page_t m, const char *file, int line);
+void vm_page_lock_assert_KBI(vm_page_t m, int a, const char *file, int line);
+
#ifdef INVARIANTS
void vm_page_object_lock_assert(vm_page_t m);
#defineVM_PAGE_OBJECT_LOCK_ASSERT(m) vm_page_object_lock_assert(m)
pgpyNMDth73tZ.pgp
Description: PGP signature
Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]
2011/11/18 Attilio Rao : > 2011/11/18 Attilio Rao : >> 2011/11/18 Kostik Belousov : >>> On Fri, Nov 18, 2011 at 11:40:28AM +0100, Attilio Rao wrote: 2011/11/16 Kostik Belousov : > On Tue, Nov 15, 2011 at 07:15:01PM +0100, Attilio Rao wrote: >> 2011/11/7 Kostik Belousov : >> > On Mon, Nov 07, 2011 at 11:45:38AM -0600, Alan Cox wrote: >> >> Ok. I'll offer one final suggestion. Please consider an alternative >> >> suffix to "func". Perhaps, "kbi" or "KBI". In other words, >> >> something >> >> that hints at the function's reason for existing. >> > >> > Sure. Below is the extraction of only vm_page_lock() bits, together >> > with the suggested rename. When Attilio provides the promised >> > simplification >> > of the mutex KPI, this can be reduced. >> >> My tentative patch is here: >> http://www.freebsd.org/~attilio/mutexfileline.patch >> >> I need to make more compile testing later, but it already compiles >> GENERIC + modules fine on HEAD. >> >> The patch provides a common entrypoint, option independent, for both >> fast case and debug/compat case. >> Additively, it almost entirely fixes the standard violation of the >> reserved namespace, as you described (the notable exception being the >> macro used in the fast path, that I want to fix as well, but in a >> separate commit). >> >> Now the file/line couplet can be passed to the "_" suffix variant of >> the flag functions. > Yes, this is exactly KPI that I would use when available for the > vm_page_lock() patch. > >> >> eadler@ reviewed the mutex.h comment. >> >> Please let me know what you think about it, as long as we agree on the >> patch I'll commit it. > But I also agree with John that imposing large churn due to the > elimination > of the '__' prefix is too late now. At least it will make the change > non-MFCable. Besides, we already lived with the names for 10+ years. > > I will be happy to have the part of the patch that exports the > mtx_XXX_(mtx, > file, line) defines which can be used without taking care of LOCK_DEBUG > or MUTEX_NOINLINE in the consumer code. Ok, this patch should just add the compat stub: http://www.freebsd.org/~attilio/mutexfileline2.patch >>> Am I right that I would use mtx_lock_(mtx, file, line) etc ? >>> If yes, I am fine with it. >> >> Yes that is correct. >> >> However, I'm a bit confused on one aspect: would you mind using >> _mtx_lock_flags() instead? >> If you don't mind the "underscore namespace violation" I think I can >> make a much smaller patch against HEAD for it. >> >> Otherwise, the one now posted should be ok. > > After thinking more about it, I think that is basically the shorter > version I can came up with. > > Please consider: > http://www.freebsd.org/~attilio/mutexfileline2.patch This is now committed as r227758,227759, you can update your patch now. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Adding disk firmware programming capability to camcontrol
On Sunday 20 November 2011 15:24:41 Andriy Gapon wrote: > > I have tried issuing a TUR to all my drives to see if it was controller > > or drive specific, but all of them return the same error (The drives are > > Seagate, Hitachi and WD). > > > > What am I doing wrong? > > You are sending SCSI commands to a (S)ATA drive. Ah... Bummer... I thought that might be the issue. I had kind of hoped that the code would also handle the ATA drives as well, but still this will be a great feature to have in camcontrol as it is. Thanks Peg ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Adding disk firmware programming capability to camcontrol
on 20/11/2011 16:54 Pegasus Mc Cleaft said the following: > Hi Nima, > > I have tried your latest patch against current, but I am having > difficulty > getting it to work. I was wondering, is this feature limited to SCSI drives? > I have been trying it against my SATA drives but it looks like it is failing > on issuing a TUR. > > IE: > > feathers# camcontrol fwdownload ada5 -f JP0NB3MA.BD -s -v > Running in simulation mode > camcontrol: Device is not ready > (pass5:ahcich4:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > (pass5:ahcich4:0:0:0): CAM status: CCB request was invalid > Firmware download failed > > > I have tried issuing a TUR to all my drives to see if it was controller or > drive specific, but all of them return the same error (The drives are > Seagate, > Hitachi and WD). > > What am I doing wrong? You are sending SCSI commands to a (S)ATA drive. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Adding disk firmware programming capability to camcontrol
Hi Nima, I have tried your latest patch against current, but I am having difficulty getting it to work. I was wondering, is this feature limited to SCSI drives? I have been trying it against my SATA drives but it looks like it is failing on issuing a TUR. IE: feathers# camcontrol fwdownload ada5 -f JP0NB3MA.BD -s -v Running in simulation mode camcontrol: Device is not ready (pass5:ahcich4:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (pass5:ahcich4:0:0:0): CAM status: CCB request was invalid Firmware download failed I have tried issuing a TUR to all my drives to see if it was controller or drive specific, but all of them return the same error (The drives are Seagate, Hitachi and WD). What am I doing wrong? Ta Peg ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ee (easy editor) bugged on 9.0?
On Sat, Nov 19, 2011 at 6:07 PM, Stefan Bethke wrote: > Am 19.11.2011 um 17:29 schrieb Jason Edwards: > >> Dear list, >> >> Has anyone noticed the easy editor is quite bugged on 9.0? On console >> direct access, opening the easy editor has several bugs: >> >> 1) the cursor starts on line 2 instead of line 1 >> 2) the line numbering is printed on line 1 instead of the boundary (line 0) >> 3) the keys page up and page down bring the escape menu >> >> Strange enough, if I SSH into the box the ee editor works normally. So >> I'm wondering if this is something other people have noticed? Just >> want to exclude the possibility of me doing something wrong. >> >> I've noticed this behavior on 9-CURRENT, 9.0-RC1 as well as 9.0-RC2, >> amd64. GENERIC kernel and tested inside Virtualbox. > > Working fine here on 9.0-RC1. > > Is this a fresh install, or did you upgrade? Have you updated your ttys to > set the terminal type to xterm instead of cons25? This is a fresh install. I do make a LiveCD using scripted tools. But it pretty much is a vanilla FreeBSD install with just some packages preinstalled (webserver, php, etc). The only relevant changes I think are a change to /etc/ttys. But when I revert the file back to the defaults, the problem stays. I thought that perhaps Virtualbox had something to do with it, but it seems to happen on a real system as well. Some of you asked for the environmental settings. Using 'env' the output begins with: -- on console -- TERM=cons25 SHELL=/usr/local/bin/bash -- via SSH -- TERM=xterm SHELL=/usr/local/bin/bash Via SSH the ee editor works as it should. On the console it is bugged. Regards, Jason ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers
On Sat, Nov 19, 2011 at 07:56:20PM +0200, Kostik Belousov wrote: > I fully agree with an idea that compiler is not an authorative source > of the knowledge of the FreeBSD version. Even more, I argue that we shall > not rely on compiler for this at all. Ideally, we should be able to > build FreeBSD using the stock compilers without local modifications. > Thus relying on the symbols defined by compiler, and not the source > is the thing to avoid and consistently remove. > > We must do this to be able to use third-party tooldchain for FreeBSD builds. > > That said, why not define __FreeBSD_kernel as equal to __FreeBSD_version ? > And then make more strong wording about other systems that use the macro, > e.g. remove 'may' from the kFreeBSD example. > Also, please remove the smile from comment. Ok. New patch attached. -- Robert Millan Index: sys/sys/param.h === --- sys/sys/param.h (revision 227580) +++ sys/sys/param.h (working copy) @@ -60,6 +60,22 @@ #undef __FreeBSD_version #define __FreeBSD_version 101 /* Master, propagated to newvers */ +/* + * __FreeBSD_kernel__ indicates that this system uses the kernel of FreeBSD, + * which by definition is always true on FreeBSD. This macro is also defined + * on other systems that use the kernel of FreeBSD, such as GNU/kFreeBSD + * + * It is tempting to use this macro in userland code when we want to enable + * kernel-specific routines, and in fact it's fine to do this in code that + * is part of FreeBSD itself. However, be aware that as presence of this + * macro is still not widespread (e.g. older FreeBSD versions, 3rd party + * compilers, etc), it is STRONGLY DISCOURAGED to check for this macro in + * external applications without also checking for __FreeBSD__ as an + * alternative. + */ +#undef __FreeBSD_kernel__ +#define __FreeBSD_kernel__ __FreeBSD_version + #ifdef _KERNEL #define P_OSREL_SIGWAIT 70 #define P_OSREL_SIGSEGV 74 signature.asc Description: Digital signature
