Re: FreeBSD installers and future direction
On 5/27/13 6:53 PM, Nathan Whitehorn wrote: On 05/27/13 20:40, Alfred Perlstein wrote: On 5/27/13 2:23 PM, Bruce Cran wrote: On 27/05/2013 21:28, Alfred Perlstein wrote: On 5/27/13 11:40 AM, Bruce Cran wrote: Yes. Is this a joke? It probably /was/ too short a reply. Personally I think there should be a single UI and scripting interface across all platforms. We should try and get pc-sysinstall running on all of them first in case there's some problem that means it can't be done, in which case we'd need to use a different backend. There are just going to be certain platforms that make it EASY to do cool things. We should embrace that! That's why there are different platforms! Some are great for low power, others are great for graphics, cpu power, gpu, networking etc. If we always go for the lowest common denominator then we are crippling all the platforms for no one's benefit. Even if something CAN be done, if it is very difficult, or just never happening, then we can't limit everyone's experience based on the more difficult and/or resource strapped platforms. It's just not good business. Yes, and all of this cuts both ways: pc-sysinstall has no wireless setup support, for instance. Right now we support what we support because it is the most feature-complete thing we have, not just on tier-2 platforms but also on x86. To bring this discussion back to the ground, the fact is that we lack an installer that has both internal support for ZFS and a UI. One of the reasons for this is that making a good expressive UI for ZFS is a non-trivial undertaking given its enormous flexibility. The bsdinstall partition editor has been written to be extensible for this, and several people have started writing code to do it, but no one ended up having time to finish. Probably a reasonable thing to do is to start with supporting only a minimal set of features. If anyone felt like actually writing this code, I'm sure it would be appreciated by all and be more productive than email exchanges. -Nathan I'm sure if there was a list of reasonable things, such as wireless then pc-sysinstall could be augmented. This is the first I've heard of that. All the other complaints have been based on portability. Is that all that is required now, wireless? -Alfred -Alfred ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD installers and future direction
On May 26, 2013, at 12:37 PM, Teske, Devin wrote: > > On May 26, 2013, at 11:14 AM, Bruce Cran wrote: > >> On 26/05/2013 18:54, Teske, Devin wrote: >>> http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/harshbhatt/1 >> >> "This proposal is not made public, and you are not the student who submitted >> the proposal, nor are you a mentor for the organization it was submitted to." >> > > So, uh… register? > > I can see all private projects and all I did was register with google-melange. > > I'm not aware of a way to make it public versus private. The project was not slotted. :( -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD installers and future direction
On 05/27/13 20:40, Alfred Perlstein wrote: On 5/27/13 2:23 PM, Bruce Cran wrote: On 27/05/2013 21:28, Alfred Perlstein wrote: On 5/27/13 11:40 AM, Bruce Cran wrote: Yes. Is this a joke? It probably /was/ too short a reply. Personally I think there should be a single UI and scripting interface across all platforms. We should try and get pc-sysinstall running on all of them first in case there's some problem that means it can't be done, in which case we'd need to use a different backend. There are just going to be certain platforms that make it EASY to do cool things. We should embrace that! That's why there are different platforms! Some are great for low power, others are great for graphics, cpu power, gpu, networking etc. If we always go for the lowest common denominator then we are crippling all the platforms for no one's benefit. Even if something CAN be done, if it is very difficult, or just never happening, then we can't limit everyone's experience based on the more difficult and/or resource strapped platforms. It's just not good business. Yes, and all of this cuts both ways: pc-sysinstall has no wireless setup support, for instance. Right now we support what we support because it is the most feature-complete thing we have, not just on tier-2 platforms but also on x86. To bring this discussion back to the ground, the fact is that we lack an installer that has both internal support for ZFS and a UI. One of the reasons for this is that making a good expressive UI for ZFS is a non-trivial undertaking given its enormous flexibility. The bsdinstall partition editor has been written to be extensible for this, and several people have started writing code to do it, but no one ended up having time to finish. Probably a reasonable thing to do is to start with supporting only a minimal set of features. If anyone felt like actually writing this code, I'm sure it would be appreciated by all and be more productive than email exchanges. -Nathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD installers and future direction
On 5/27/13 2:23 PM, Bruce Cran wrote: On 27/05/2013 21:28, Alfred Perlstein wrote: On 5/27/13 11:40 AM, Bruce Cran wrote: Yes. Is this a joke? It probably /was/ too short a reply. Personally I think there should be a single UI and scripting interface across all platforms. We should try and get pc-sysinstall running on all of them first in case there's some problem that means it can't be done, in which case we'd need to use a different backend. There are just going to be certain platforms that make it EASY to do cool things. We should embrace that! That's why there are different platforms! Some are great for low power, others are great for graphics, cpu power, gpu, networking etc. If we always go for the lowest common denominator then we are crippling all the platforms for no one's benefit. Even if something CAN be done, if it is very difficult, or just never happening, then we can't limit everyone's experience based on the more difficult and/or resource strapped platforms. It's just not good business. -Alfred ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD installers and future direction
On 05/27/13 16:23, Bruce Cran wrote: On 27/05/2013 21:28, Alfred Perlstein wrote: On 5/27/13 11:40 AM, Bruce Cran wrote: Yes. Is this a joke? It probably /was/ too short a reply. Personally I think there should be a single UI and scripting interface across all platforms. We should try and get pc-sysinstall running on all of them first in case there's some problem that means it can't be done, in which case we'd need to use a different backend. I'd point out that bsdinstall does have a scripting interface now as well. -Nathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD installers and future direction
On 27/05/2013 21:28, Alfred Perlstein wrote: On 5/27/13 11:40 AM, Bruce Cran wrote: Yes. Is this a joke? It probably /was/ too short a reply. Personally I think there should be a single UI and scripting interface across all platforms. We should try and get pc-sysinstall running on all of them first in case there's some problem that means it can't be done, in which case we'd need to use a different backend. -- Bruce ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD installers and future direction
I heard there was some discussion at BSDCan about the direction of a future FreeBSD installer. Considering we currently have bsdinstall, pc-sysinstall, the best would be removing it at all and adding instruction how to install by hand. At least someone that install FreeBSD will know what he/she actually did, and what to do then in case of emergency or how to say.. move the system ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD installers and future direction
On 5/27/13 11:40 AM, Bruce Cran wrote: On 27/05/2013 19:03, Alfred Perlstein wrote: Do we always have to seek the lowest common denominator for our user experience? Yes. Is this a joke? -Alfred ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Performance improvement to strnlen().
Hello Tim,
Thank you for the review; replies inline. Note that all my performance
discussion is for amd64, with a few tests of x86, and it's all on the
machine described in my initial email (a Lynnfield Xeon), as I don't
have any other FreeBSD platform to test on. Testing and performance
measurement on other platforms would be appreciated.
Thanks,
Lee
On 2013-05-27 14:26, Tim Kientzle wrote:
Index: strnlen.c
===
diff --git a/head/lib/libc/string/strnlen.c
b/head/lib/libc/string/strnlen.c
--- a/head/lib/libc/string/strnlen.c(revision 250951)
+++ b/head/lib/libc/string/strnlen.c(working copy)
@@ -1,5 +1,6 @@
/*-
- * Copyright (c) 2009 David Schultz
+ * Copyright (c) 2009, 2010 Xin LI
+ * Copyright (c) 2013 Lee Thomas
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or
without
@@ -27,16 +28,91 @@
#include
__FBSDID("$FreeBSD$");
+#include
+#include
#include
+/*
+ * Portable strnlen() for 32-bit and 64-bit systems.
+ *
+ * Rationale: it is generally much more efficient to do word length
+ * operations and avoid branches on modern computer systems, as
+ * compared to byte-length operations with a lot of branches.
+ *
+ * The expression:
+ *
+ * ((x - 0x0101) & ~x & 0x8080)
+ *
+ * would evaluate to a non-zero value iff any of the bytes in the
+ * original word is zero.
+ *
+ * On multi-issue processors, we can divide the above expression
into:
+ * a) (x - 0x0101)
+ * b) (~x & 0x8080)
+ * c) a & b
+ *
+ * Where, a) and b) can be partially computed in parallel.
+ *
+ * The algorithm above is found on "Hacker's Delight" by
+ * Henry S. Warren, Jr.
+ */
+
+/* Magic numbers for the algorithm */
+#if LONG_BIT == 32
+static const unsigned long mask01 = 0x01010101;
+static const unsigned long mask80 = 0x80808080;
+#elif LONG_BIT == 64
+static const unsigned long mask01 = 0x0101010101010101;
+static const unsigned long mask80 = 0x8080808080808080;
+#else
+#error Unsupported word size
+#endif
+
+#defineLONGPTR_MASK (sizeof(long) - 1)
I would not use this at all; (sizeof(long) - 1) is a common
expression that your audience probably understands
more quickly than "LONGPTR_MASK".
This is simply copy-pasted from our strlen implementation; I wanted to
leave it as close to that implementation as possible, rather than
rewrite the whole thing. I could refactor the common stuff out of both,
though it would require a common implementation header for both (The
style guidelines for which I don't know), and I'm not sure it would be a
benefit to code legibility, anyways. Would it be worth cleaning
strnlen.c up, at the cost of an increased diff with strlen.c? Maybe both
should be cleaned up in the same ways? I'm willing to do any of these if
you think it would be worth the code churn.
+
size_t
-strnlen(const char *s, size_t maxlen)
+strnlen(const char *str, size_t maxlen)
{
- size_t len;
+ const char *stop, *short_stop;
+ const char *p;
+ const unsigned long *lp;
+ long va, vb;
- for (len = 0; len < maxlen; len++, s++) {
- if (!*s)
- break;
+ if (maxlen==0) return 0;
+
+ stop=str+maxlen;
+ /*
+* Before trying the hard (unaligned byte-by-byte access) way
+* to figure out whether there is a nul character, try to see
+* if there is a nul character is within this accessible word
+* first.
+*
+* p and (p & ~LONGPTR_MASK) must be equally accessible since
+* they always fall in the same memory page, as long as page
+* boundaries is integral multiple of word size.
+*/
+ lp = (const unsigned long *)((uintptr_t)str & ~LONGPTR_MASK);
+ lp++;
Have you tested to see whether the extra work you're
doing for the initial segment really gains you much? I
would have used a simpler byte-by-byte check as
follows:
Yes, it is worth it, with a pretty good margin for small strings, even
under pretty high assumptions about the frequency of zero in the data
before the start of the string. I tried various things, and this is the
fastest I found.
p = s;
while (maxlen-- > 0 && p < (const char *)lp) {
if (*p == '\0')
return (p - s);
}
while (maxlen > 0) {
… complicated test of *lp …
maxlen -= sizeof(*lp);
}
Few points here:
* This form of the initial segment test doesn't get surprised
by a NUL byte just before the string. Yours does a bunch of
extra work in that case.
* Duff's device might help unroll the first loop; would require
testing to see if it was faster. For something this simple, it
might not be.
* Your version tests the first word twice (once in the
initial check and then again at the start of the word-sized
pass). This version doesn't.
Actually, it doesn't. Note the 'lp++' on line 97, after computing v
Re: /bin/sh => STDIN & functions, var scope messing
from SH(1)
"Note that unlike some other shells, sh executes each process in a pipe-
line with more than one command in a subshell environment and as a
child
of the sh process."
I'm taking this to mean that redirecting to sh_f has sh_f execute in a
subshell in which global_scope_var changes, but the original shell's copy
is uncahnged.
On Mon, May 27, 2013 at 2:42 PM, wrote:
> 9.1-RELEASE-p3
> ---
> #!/bin/sh
>
> sh_f ()
> {
> global_scope_var=7463457
> }
>
> yes | sh_f
> echo "$global_scope_var"
>
> echo '
> Now without /usr/bin/yes (maybe it is STDIN issue, instead) ?!?
> '
>
> sh_f
> echo "$global_scope_var"
> ---
>
>
> Domagoj Smolčić
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
/bin/sh => STDIN & functions, var scope messing
9.1-RELEASE-p3
---
#!/bin/sh
sh_f ()
{
global_scope_var=7463457
}
yes | sh_f
echo "$global_scope_var"
echo '
Now without /usr/bin/yes (maybe it is STDIN issue, instead) ?!?
'
sh_f
echo "$global_scope_var"
---
Domagoj Smolčić
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD installers and future direction
On May 27, 2013, at 11:03 AM, Alfred Perlstein wrote: > On 5/27/13 9:56 AM, Bruce Cran wrote: >> On 27/05/2013 16:48, Alfred Perlstein wrote: >>> Why can we not use in the interim use pc-sysinstall on the platforms that >>> it performs best on and use bsdinstall on the others? >> >> Because pc-sysinstall doesn't have a UI - it's only a backend. If we update >> bsdinstall to use it, then it won't work on other platforms. >> > This still doesn't make sense to me. Why can bsdinstall not conditionally > use it? > Because, believe it or not, not all programs are split in twain, having a front-end and a back-end. I'm not defending it, and I'm not promoting it, but bsdinstall does things in a different way where pc-sysinstall wants to be just a back-end. bsdinstall would have to go through a major revision to make it use any external back-end. Currently it's one self-enclosed entity. > Do we always have to seek the lowest common denominator for our user > experience? > When the situation*is* that the release engineers can only embrace one installer for the release media of more than just x86 architecture, the answer is… yes (common denominator required). My thoughts are… let me toil on a new installer and then we can think about opening the can of worms that is "how to enable conditional installers." HINT: I already solved that problem… by modifying the boot loader Forth menu to allow the creation of custom boot menus. Now all we need is another installer to elicit the use of that code to present the choice the user. However… (and this is a big however), unless the 2nd choice installer is as half-as-bad as bsdinstall… I don't see why it wouldn't just replace it (therefore negating the need to invoke that code I put in to allow multiple choice installers at beastie menu). -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD installers and future direction
On 27/05/2013 19:03, Alfred Perlstein wrote: Do we always have to seek the lowest common denominator for our user experience? Yes. -- Bruce ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Performance improvement to strnlen().
>
> Index: strnlen.c
> ===
> diff --git a/head/lib/libc/string/strnlen.c b/head/lib/libc/string/strnlen.c
> --- a/head/lib/libc/string/strnlen.c (revision 250951)
> +++ b/head/lib/libc/string/strnlen.c (working copy)
> @@ -1,5 +1,6 @@
> /*-
> - * Copyright (c) 2009 David Schultz
> + * Copyright (c) 2009, 2010 Xin LI
> + * Copyright (c) 2013 Lee Thomas
> * All rights reserved.
> *
> * Redistribution and use in source and binary forms, with or without
> @@ -27,16 +28,91 @@
> #include
> __FBSDID("$FreeBSD$");
>
> +#include
> +#include
> #include
>
> +/*
> + * Portable strnlen() for 32-bit and 64-bit systems.
> + *
> + * Rationale: it is generally much more efficient to do word length
> + * operations and avoid branches on modern computer systems, as
> + * compared to byte-length operations with a lot of branches.
> + *
> + * The expression:
> + *
> + * ((x - 0x0101) & ~x & 0x8080)
> + *
> + * would evaluate to a non-zero value iff any of the bytes in the
> + * original word is zero.
> + *
> + * On multi-issue processors, we can divide the above expression into:
> + * a) (x - 0x0101)
> + * b) (~x & 0x8080)
> + * c) a & b
> + *
> + * Where, a) and b) can be partially computed in parallel.
> + *
> + * The algorithm above is found on "Hacker's Delight" by
> + * Henry S. Warren, Jr.
> + */
> +
> +/* Magic numbers for the algorithm */
> +#if LONG_BIT == 32
> +static const unsigned long mask01 = 0x01010101;
> +static const unsigned long mask80 = 0x80808080;
> +#elif LONG_BIT == 64
> +static const unsigned long mask01 = 0x0101010101010101;
> +static const unsigned long mask80 = 0x8080808080808080;
> +#else
> +#error Unsupported word size
> +#endif
> +
> +#define LONGPTR_MASK (sizeof(long) - 1)
I would not use this at all; (sizeof(long) - 1) is a common
expression that your audience probably understands
more quickly than "LONGPTR_MASK".
> +
> size_t
> -strnlen(const char *s, size_t maxlen)
> +strnlen(const char *str, size_t maxlen)
> {
> - size_t len;
> + const char *stop, *short_stop;
> + const char *p;
> + const unsigned long *lp;
> + long va, vb;
>
> - for (len = 0; len < maxlen; len++, s++) {
> - if (!*s)
> - break;
> + if (maxlen==0) return 0;
> +
> + stop=str+maxlen;
> + /*
> + * Before trying the hard (unaligned byte-by-byte access) way
> + * to figure out whether there is a nul character, try to see
> + * if there is a nul character is within this accessible word
> + * first.
> + *
> + * p and (p & ~LONGPTR_MASK) must be equally accessible since
> + * they always fall in the same memory page, as long as page
> + * boundaries is integral multiple of word size.
> + */
> + lp = (const unsigned long *)((uintptr_t)str & ~LONGPTR_MASK);
> + lp++;
Have you tested to see whether the extra work you're
doing for the initial segment really gains you much? I
would have used a simpler byte-by-byte check as
follows:
p = s;
while (maxlen-- > 0 && p < (const char *)lp) {
if (*p == '\0')
return (p - s);
}
while (maxlen > 0) {
… complicated test of *lp …
maxlen -= sizeof(*lp);
}
Few points here:
* This form of the initial segment test doesn't get surprised
by a NUL byte just before the string. Yours does a bunch of
extra work in that case.
* Duff's device might help unroll the first loop; would require
testing to see if it was faster. For something this simple, it
might not be.
* Your version tests the first word twice (once in the
initial check and then again at the start of the word-sized
pass). This version doesn't.
* Comparison with zero is often free, so a countdown to zero
is often faster than a count up to a computed limit.
This assumes that 'lp' is pointing to the first aligned word
at or after the beginning of the string.
Your version does not leave lp pointing to
the beginning of the string when the string is initially
already aligned. If the string is already fully aligned, my
version avoids the initial check entirely.
To compute 'lp' as a pointer to the first full word
at or after the beginning of the string:
lp = (const unsigned long *)
(
(
(uintptr_t)str + sizeof(*lp) - 1
)
&
(
sizeof(*lp) - 1
)
);
I've broken this onto multiple lines to illustrate the structure;
the final code would of course be a little more compact.
Also note the use of sizeof(*lp) rather than
sizeof(long) or sizeof(unsigned long); this way,
you guarantee that the sizeof() matches lp even if someone
comes along later and changes the declaration of lp.
> + va = (*lp - mask01);
> + vb = ((~*lp) & mask80);
> + if (va & vb) {
> + /* Check if we have \0 in the first part */
> + short_stop=(con
Re: FreeBSD installers and future direction
On 5/27/13 9:56 AM, Bruce Cran wrote: On 27/05/2013 16:48, Alfred Perlstein wrote: Why can we not use in the interim use pc-sysinstall on the platforms that it performs best on and use bsdinstall on the others? Because pc-sysinstall doesn't have a UI - it's only a backend. If we update bsdinstall to use it, then it won't work on other platforms. This still doesn't make sense to me. Why can bsdinstall not conditionally use it? Do we always have to seek the lowest common denominator for our user experience? -Alfred ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
>3955MiB of swap space
I have 4 hard drives, each containing a swap partition of size 1023MiB. I get: warning: total configured swap (1178880 pages) exceeds maximum recommended amount (1012480 pages). warning: increase kern.maxswzone or reduce amount of swap. Is the warning safe to ignore? I assume that only 3955MiB of swap space will be used instead of 4092MiB, because using more would cause overhead. I do not prefer to repartition the drives for them to have swap partitions each of size (3955/4)MiB. By the way, is swapping distributed evenly among the drives? How? Is there a downfall when one of the drives is outstandingly slow? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD installers and future direction
On 27/05/2013 16:48, Alfred Perlstein wrote: Why can we not use in the interim use pc-sysinstall on the platforms that it performs best on and use bsdinstall on the others? Because pc-sysinstall doesn't have a UI - it's only a backend. If we update bsdinstall to use it, then it won't work on other platforms. -- Bruce ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD installers and future direction
On 27 May 2013 03:10, "Daniel Eischen" wrote: > > On Mon, 27 May 2013, Teske, Devin wrote: >> >> >> I don't think there's any reason why we have to write it in C if we can write >> it in sh. > > > I don't really care one way or the other (C or sh), but > I can say that I can understand(*) well structured C a lot > better than well structured sh. Having something more > strongly typed certainly helps understanding. > > (*) Assuming some level of complexity (I know that's > subjective). I think it's all down to familiarity. I suppose sh is more resistant to many stupid bugs and handles strings well But it has its own troubles too of course. Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD installers and future direction
On 5/25/13 8:45 PM, Teske, Devin wrote: On May 25, 2013, at 7:51 PM, Super Bisquit wrote: Please don't turn this into an architecture dependent mess. PCBSD is i386 & AMD64 only. There's a GSoC project (of which I'm potential mentor) to fix that. However, you are entirely right… we can't in all seriousness even think about using pc-sysinstall until it is solid on all architectures as bsdinstall already is. GSoC project is: "Making pc-sysinstall FreeBSD ready by porting it to multiple architectures" Why can we not use in the interim use pc-sysinstall on the platforms that it performs best on and use bsdinstall on the others? It doesn't make sense for us to hold up some platform like this at all. Maybe no one has thought of this? Basically use pc-sysinstall on amd64 and i386 and use bsdinstall on the other platforms until they catch up? -Alfred ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD installers and future direction
On 5/26/13 10:03 AM, Dirk Engling wrote: On 26.05.13 04:51, Super Bisquit wrote: Please don't turn this into an architecture dependent mess. PCBSD is i386 & AMD64 only. Read my email thoroughly and notice that I never seriously considered using pc-sysinstall after looking into it. Don't worry. Why is that exactly? A number of people are using it successfully to install ZFS based systems. -Alfred ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: preemptive kernel
[trimmed cc] on 27/05/2013 15:29 Orit Moskovich said the following: >>From what I've read in subr_taskqueue.c taskqueue_swi, taskqueue_swi_giant >>and taskqueue_fast are all implemented using swi_add which calls >>ithread_create(). > Is there any performance difference between them. Is one of the above or > ithread given to bus_setup_intr preferable on the other? The differences are described in taskqueue(9) "Predefined Task Queues" section. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
RE: preemptive kernel
>From what I've read in subr_taskqueue.c taskqueue_swi, taskqueue_swi_giant and >taskqueue_fast are all implemented using swi_add which calls ithread_create(). Is there any performance difference between them. Is one of the above or ithread given to bus_setup_intr preferable on the other? -Original Message- From: Andriy Gapon [mailto:a...@freebsd.org] Sent: Monday, May 27, 2013 03:18 PM To: Orit Moskovich Cc: Konstantin Belousov; freebsd-hackers@freebsd.org Subject: Re: preemptive kernel on 27/05/2013 10:21 Orit Moskovich said the following: > What is actually the difference between deferring a filter routine's work > using an ithread given to bus_setup_intr, or using the global taskqueue_swi > (implemented using interrupt thread)? I think you mean taskqueue_fast. The difference is only in how much code you need to write. I do not think there is any significant difference in the resulting functionality. > What do you mean that the functionality is locked under INTR_FILTER? Please see the code. You have to use option INTR_FILTER to get the behavior I described earlier. > -Original Message- > From: Andriy Gapon [mailto:a...@freebsd.org] > Sent: Monday, May 27, 2013 10:11 AM > To: Konstantin Belousov > Cc: Orit Moskovich; freebsd-hackers@freebsd.org > Subject: Re: preemptive kernel > > on 27/05/2013 09:34 Konstantin Belousov said the following: >> Having both filter and ithread for the same interrupt is apparently >> possible but weird. I do not see anything which would prevent >> interrupt filter from being executed while the ithread is running. >> But again, this is very unusual setup. > > I wouldn't call it weird, but, yes, it is rare. It's a pretty normal > configuration when the filter acts as a filter and the handler acts as a > handler (in ithread). In other words, it would be a replacement for a > configuration where a filter is used and the filter offloads actual work to > non-interrupt context via a e.g. taskqueue. > But, hmm, this functionality is probably locked under INTR_FILTER option. > > -- > Andriy Gapon > -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: preemptive kernel
on 27/05/2013 10:21 Orit Moskovich said the following: > What is actually the difference between deferring a filter routine's work > using an ithread given to bus_setup_intr, or using the global taskqueue_swi > (implemented using interrupt thread)? I think you mean taskqueue_fast. The difference is only in how much code you need to write. I do not think there is any significant difference in the resulting functionality. > What do you mean that the functionality is locked under INTR_FILTER? Please see the code. You have to use option INTR_FILTER to get the behavior I described earlier. > -Original Message- > From: Andriy Gapon [mailto:a...@freebsd.org] > Sent: Monday, May 27, 2013 10:11 AM > To: Konstantin Belousov > Cc: Orit Moskovich; freebsd-hackers@freebsd.org > Subject: Re: preemptive kernel > > on 27/05/2013 09:34 Konstantin Belousov said the following: >> Having both filter and ithread for the same interrupt is apparently >> possible but weird. I do not see anything which would prevent >> interrupt filter from being executed while the ithread is running. >> But again, this is very unusual setup. > > I wouldn't call it weird, but, yes, it is rare. It's a pretty normal > configuration when the filter acts as a filter and the handler acts as a > handler (in ithread). In other words, it would be a replacement for a > configuration where a filter is used and the filter offloads actual work to > non-interrupt context via a e.g. taskqueue. > But, hmm, this functionality is probably locked under INTR_FILTER option. > > -- > Andriy Gapon > -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Performance improvement to strnlen().
On 27 May 2013 12:20, Lee Thomas wrote: > On 2013-05-27 04:37, Václav Zeman wrote: >> >> On 26 May 2013 21:01, Lee Thomas wrote: >>> >>> On 2013-05-26 08:00, Václav Zeman wrote: On 05/25/2013 10:27 PM, Lee Thomas wrote: > > > + lp = (const unsigned long *)((uintptr_t)str & ~LONGPTR_MASK); > + va = (*lp - mask01); > + vb = ((~*lp) & mask80); I do not think that this correct C. This is type punning violating the rules of the language. >>> >>> >>> >>> Hello Václav, >>> >>> The aliasing here is safe, because there are no writes through either of >>> the >>> pointers, and the reads are correctly aligned. >> >> I disagree. IANALL but AFAIK, this is simply not allowed by the >> language => UB => even though it seems to work in this instance, you >> are just lucky the UB is actually doing what you expect. >> >> -- >> VZ > > > Hello Václav, > > I am not an expert in C either, so you may be right that this is technically > illegal. However, I copied this code from strlen.c, which has had it, and > still has it, for 4.5 years, and I can't see any way any alias analysis done > by the compiler could invalidate this code. In addition, there are many > places in the kernel, and in other codebases I've worked on, where this kind > of type conversion is done. See for instance > /sys/amd64/amd64/vm_macdep.c:200, where we compute the base of a thread's > stackframe from a pointer to an unrelated type of 'struct pcb', and then > write to it. > > I am willing to uglify the code in the way you suggest if that is the > general concensus, but I think the code as it stands is both safe and more > legible. You could always put the three lines into a macro to keep the strnlen() more readable. -- VZ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Performance improvement to strnlen().
On 27 May 2013 12:25, Adam Nowacki wrote: > On 2013-05-27 10:37, Václav Zeman wrote: >> >> On 26 May 2013 21:01, Lee Thomas wrote: >>> >>> On 2013-05-26 08:00, Václav Zeman wrote: On 05/25/2013 10:27 PM, Lee Thomas wrote: > > > + lp = (const unsigned long *)((uintptr_t)str & ~LONGPTR_MASK); > + va = (*lp - mask01); > + vb = ((~*lp) & mask80); I do not think that this correct C. This is type punning violating the rules of the language. >>> >>> >>> >>> Hello Václav, >>> >>> The aliasing here is safe, because there are no writes through either of >>> the >>> pointers, and the reads are correctly aligned. >> >> I disagree. IANALL but AFAIK, this is simply not allowed by the >> language => UB => even though it seems to work in this instance, you >> are just lucky the UB is actually doing what you expect. > > > It is not possible to tell if the result would be undefined by looking at > the strnlen function alone. IMHO, it is possible to look at the strnlen() function code and see the UB there. UB is is there even if it does not manifest itself to you by producing executable that gives you unexpected results or that crashes. > Internally it doesn't break any aliasing rules > as char and long are allowed to alias. UB can only happen when the input > string was created with incompatible type (not char and not long) and the > strnlen function got inlined. No, you got it wrong here. You can access any type of object by char pointer. However the reverse is not true. > Preventing inlining would be sufficient to > guarantee correctness in any case. Preventing inlining is masking the problem but it does not make it go away. Also, in these days when compilers can optimize across translation units, you cannot be sure the UB will be masked even if no inlining happens. -- VZ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Performance improvement to strnlen().
On 2013-05-27 10:37, Václav Zeman wrote: On 26 May 2013 21:01, Lee Thomas wrote: On 2013-05-26 08:00, Václav Zeman wrote: On 05/25/2013 10:27 PM, Lee Thomas wrote: + lp = (const unsigned long *)((uintptr_t)str & ~LONGPTR_MASK); + va = (*lp - mask01); + vb = ((~*lp) & mask80); I do not think that this correct C. This is type punning violating the rules of the language. Hello Václav, The aliasing here is safe, because there are no writes through either of the pointers, and the reads are correctly aligned. I disagree. IANALL but AFAIK, this is simply not allowed by the language => UB => even though it seems to work in this instance, you are just lucky the UB is actually doing what you expect. It is not possible to tell if the result would be undefined by looking at the strnlen function alone. Internally it doesn't break any aliasing rules as char and long are allowed to alias. UB can only happen when the input string was created with incompatible type (not char and not long) and the strnlen function got inlined. Preventing inlining would be sufficient to guarantee correctness in any case. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Performance improvement to strnlen().
On 2013-05-27 04:37, Václav Zeman wrote: On 26 May 2013 21:01, Lee Thomas wrote: On 2013-05-26 08:00, Václav Zeman wrote: On 05/25/2013 10:27 PM, Lee Thomas wrote: + lp = (const unsigned long *)((uintptr_t)str & ~LONGPTR_MASK); + va = (*lp - mask01); + vb = ((~*lp) & mask80); I do not think that this correct C. This is type punning violating the rules of the language. Hello Václav, The aliasing here is safe, because there are no writes through either of the pointers, and the reads are correctly aligned. I disagree. IANALL but AFAIK, this is simply not allowed by the language => UB => even though it seems to work in this instance, you are just lucky the UB is actually doing what you expect. -- VZ Hello Václav, I am not an expert in C either, so you may be right that this is technically illegal. However, I copied this code from strlen.c, which has had it, and still has it, for 4.5 years, and I can't see any way any alias analysis done by the compiler could invalidate this code. In addition, there are many places in the kernel, and in other codebases I've worked on, where this kind of type conversion is done. See for instance /sys/amd64/amd64/vm_macdep.c:200, where we compute the base of a thread's stackframe from a pointer to an unrelated type of 'struct pcb', and then write to it. I am willing to uglify the code in the way you suggest if that is the general concensus, but I think the code as it stands is both safe and more legible. Thanks, Lee ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Performance improvement to strnlen().
Le 27/05/2013 10:37, Václav Zeman a écrit : > On 26 May 2013 21:01, Lee Thomas wrote: >> On 2013-05-26 08:00, Václav Zeman wrote: >>> >>> On 05/25/2013 10:27 PM, Lee Thomas wrote: + lp = (const unsigned long *)((uintptr_t)str & ~LONGPTR_MASK); + va = (*lp - mask01); + vb = ((~*lp) & mask80); >>> >>> I do not think that this correct C. This is type punning violating the >>> rules of the language. >> >> >> Hello Václav, >> >> The aliasing here is safe, because there are no writes through either of the >> pointers, and the reads are correctly aligned. > I disagree. IANALL but AFAIK, this is simply not allowed by the > language => UB => even though it seems to work in this instance, you > are just lucky the UB is actually doing what you expect. In that case we should rewrite strlen, it's the same code. That doesn't mean it's a good code but I really don't think it's bad. Using signedness is totally valid and what is done here appears valid too. > -- > VZ -- Florent Peterschmitt | /"\ ASCII Ribbon Campaign flor...@peterschmitt.fr| \ / - No HTML/RTF in E-mail +33 (0)6 64 33 97 92 | X - No proprietary attachments http://florent.peterschmitt.fr | / \ - Respect for open standards signature.asc Description: OpenPGP digital signature
Re: Performance improvement to strnlen().
On 26 May 2013 21:01, Lee Thomas wrote: > On 2013-05-26 08:00, Václav Zeman wrote: >> >> On 05/25/2013 10:27 PM, Lee Thomas wrote: >>> >>> + lp = (const unsigned long *)((uintptr_t)str & ~LONGPTR_MASK); >>> + va = (*lp - mask01); >>> + vb = ((~*lp) & mask80); >> >> I do not think that this correct C. This is type punning violating the >> rules of the language. > > > Hello Václav, > > The aliasing here is safe, because there are no writes through either of the > pointers, and the reads are correctly aligned. I disagree. IANALL but AFAIK, this is simply not allowed by the language => UB => even though it seems to work in this instance, you are just lucky the UB is actually doing what you expect. -- VZ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
RE: preemptive kernel
What is actually the difference between deferring a filter routine's work using an ithread given to bus_setup_intr, or using the global taskqueue_swi (implemented using interrupt thread)? What do you mean that the functionality is locked under INTR_FILTER? -Original Message- From: Andriy Gapon [mailto:a...@freebsd.org] Sent: Monday, May 27, 2013 10:11 AM To: Konstantin Belousov Cc: Orit Moskovich; freebsd-hackers@freebsd.org Subject: Re: preemptive kernel on 27/05/2013 09:34 Konstantin Belousov said the following: > Having both filter and ithread for the same interrupt is apparently > possible but weird. I do not see anything which would prevent > interrupt filter from being executed while the ithread is running. > But again, this is very unusual setup. I wouldn't call it weird, but, yes, it is rare. It's a pretty normal configuration when the filter acts as a filter and the handler acts as a handler (in ithread). In other words, it would be a replacement for a configuration where a filter is used and the filter offloads actual work to non-interrupt context via a e.g. taskqueue. But, hmm, this functionality is probably locked under INTR_FILTER option. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: preemptive kernel
on 27/05/2013 09:34 Konstantin Belousov said the following: > Having both filter and ithread for the same interrupt is apparently > possible but weird. I do not see anything which would prevent interrupt > filter from being executed while the ithread is running. But again, this > is very unusual setup. I wouldn't call it weird, but, yes, it is rare. It's a pretty normal configuration when the filter acts as a filter and the handler acts as a handler (in ithread). In other words, it would be a replacement for a configuration where a filter is used and the filter offloads actual work to non-interrupt context via a e.g. taskqueue. But, hmm, this functionality is probably locked under INTR_FILTER option. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
