Re: fuser does not list id of processes that have a file
Hi there,
Op di 16 okt. 2018 om 15:05 schreef Mateusz Guzik :
> struct reqfile {
> - uint32_tfsid;
> + uint64_tfsid;
> uint64_tfileid;
Considering that these are based on sb.st_{ino,dev}, maybe better to
use the occasion to switch these fields to dev_t and ino_t?
--
Ed Schouten
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Odd w/who behavior for the last 12 years
Hi Timur, 2018-05-28 5:26 GMT+02:00 Timur I. Bakeyev : > So I propose to remove the said patch(or make it verify only "pts/" > devices). any objections? Sounds good! Changes like the ones made in r155875 were simply workarounds to deal with processes silly enough not to write DEAD_PROCESS entries. Instead of patching up w, wall, who, etc. we should spend effort to fix these problems at the root instead. Be sure to cc me on code reviews! -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Programmatically cache line
2018-01-01 11:36 GMT+01:00 Konstantin Belousov : >> >> On x86, the CPUID instruction leaf 0x1 returns the information in >> >> %ebx register. >> > >> > Hm, weird. Why don't we extend sysctl to include this info? > > For the same reason we do not provide a sysctl to add two integers. I strongly agree with Kostik on this one. Why add stuff to the kernel, if userspace is already capable of extracting this? Adding that stuff to sysctl has the downside that it will effectively introduce yet another FreeBSDism, whereas something generic already exists. -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r326734: serial console fails: boot stuck at: Consoles: internal video/keyboard
2017-12-09 19:41 GMT+01:00 O. Hartmann : > r326734 fails to boot, > r324234 works fine. > > What the heck has changed? Could you please try to bisect SVN revisions to figure out which exact commit causes the problem? -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: reducing build times; selecting specific clang targets
Hi Michael, 2017-12-09 4:57 GMT+01:00 Michael Butler : > As clang builds for multiple targets unconditionally, it takes *days* to > build on one of my devices (700MHz Pentium-3). > > Is there a way to restrict the build targets to i386 only? If not, can we > implement one? Regardless of the discussion of how and whether this may be implemented, do take into consideration that the target specific bits in Clang only account for a minority of the build time. It is not as if Clang is literally built multiple times, once for every architecture. The build will likely still take several days, even if this got fixed. Have you considered doing builds on some other system and copying the results over? According to Wikipedia, they stopped producing Pentium III CPUs 14 years ago. Using these systems to do actual builds sounds like a waste of electricity. -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: XBOX/i386 and xlint removal
[ +rink@ for XBOX/i386 ] 2017-11-09 14:52 GMT+01:00 Konstantin Belousov : > Hello, > I created two reviews to axe two features which I personally find of > little use in modern FreeBSD. > > https://reviews.freebsd.org/D13015 xlint > https://reviews.freebsd.org/D13016 XBOX/i386 > > Reviews contain the explanations. For xlint it is just an overdue, IMO. > While for XBOX I do not have much opposition against supporting the > obsoleted platforms, but the way the port was done pollutes the sources > with too much #ifdefs. Since people often do not want to care about i386 > together with amd64, additional hurdle only makes the things worse. > > Feel free to add yourself as reviewer. I intend to commit the patches > in a week, unless strong objections expressed by the time. -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: svn commit: r322875 - head/sys/dev/nvme
2017-08-28 11:02 GMT+02:00 Mark Millard : > Based on the same main.cc as before . . . > > g++7 -std=c++98 main.cc > g++7 -Wpedantic -std=c++98 main.cc > g++7 -std=c++03 main.cc > g++7 -Wpedantic -std=c++03 main.cc > > no longer complain (so no error, no > warning). Perfect! I've committed this change as r322965. Thanks for testing! -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: svn commit: r322875 - head/sys/dev/nvme
Mark, 2017-08-25 14:53 GMT+02:00 Ed Schouten : > 2017-08-25 9:46 GMT+02:00 Mark Millard : >> It appears that at least 11.1-STABLE -r322807 does not handle >> -std=c++98 styles of use of _Static_assert for g++7 in that >> g++7 reports an error: > > Maybe we need to do something like this? > > Index: sys/sys/cdefs.h > === > --- sys/sys/cdefs.h (revision 322887) > +++ sys/sys/cdefs.h (working copy) > @@ -294,7 +294,7 @@ > #if (defined(__cplusplus) && __cplusplus >= 201103L) || \ > __has_extension(cxx_static_assert) > #define _Static_assert(x, y) static_assert(x, y) > -#elif __GNUC_PREREQ__(4,6) > +#elif __GNUC_PREREQ__(4,6) && !defined(__cplusplus) > /* Nothing, gcc 4.6 and higher has _Static_assert built-in */ > #elif defined(__COUNTER__) > #define _Static_assert(x, y) __Static_assert(x, __COUNTER__) Could you let me know whether this patch fixes the build for you? If so, I'll commit it! -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: svn commit: r322875 - head/sys/dev/nvme
2017-08-25 9:46 GMT+02:00 Mark Millard : > It appears that at least 11.1-STABLE -r322807 does not handle > -std=c++98 styles of use of _Static_assert for g++7 in that > g++7 reports an error: Maybe we need to do something like this? Index: sys/sys/cdefs.h === --- sys/sys/cdefs.h (revision 322887) +++ sys/sys/cdefs.h (working copy) @@ -294,7 +294,7 @@ #if (defined(__cplusplus) && __cplusplus >= 201103L) || \ __has_extension(cxx_static_assert) #define _Static_assert(x, y) static_assert(x, y) -#elif __GNUC_PREREQ__(4,6) +#elif __GNUC_PREREQ__(4,6) && !defined(__cplusplus) /* Nothing, gcc 4.6 and higher has _Static_assert built-in */ #elif defined(__COUNTER__) #define _Static_assert(x, y) __Static_assert(x, __COUNTER__) -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: svn commit: r322875 - head/sys/dev/nvme
2017-08-25 8:32 GMT+02:00 Mark Millard :
>> # g++49 main.cc
>> main.cc:2:15: error: expected constructor, destructor, or type conversion
>> before '(' token
>> _Static_assert(1,"Test");
Yeah, that's because GCC is such a pain in the neck compiler that it
doesn't want to expose these C11 keywords when building C++, even
though they are in the reserved namespace (_[A-Z]). GCC would be
permitted to expose these and still comply to standards. Doing so
would make things so much easier for operating system implementors,
like us. Clang does get it right, in my opinion.
We should just extend to define _Static_assert() when
using GCC in C++ mode (if we're not doing so already).
--
Ed Schouten
Nuxi, 's-Hertogenbosch, the Netherlands
KvK-nr.: 62051717
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: after r313194 on freebsd-current, lang/gcc ports require a rebuild
2017-02-28 21:00 GMT+01:00 Konstantin Belousov : > Ideally, ports should stop shipping mangled system includes, or even better, > gcc stop doing fixincludes. Amen. -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Optimising generated rules for SAT solving (5/12 are duplicates)
2016-11-24 13:13 GMT+01:00 Vsevolod Stakhov : > On 23/11/2016 16:27, Ed Schouten wrote: >> Hi Hans, >> >> 2016-11-23 15:27 GMT+01:00 Hans Petter Selasky : >>> I've made a patch to hopefully optimise SAT solving in our pkg utility. >> >> Nice! Do you by any chance have any numbers that show the performance >> improvements made by this change? Assuming that the SAT solver of >> pkg(1) uses an algorithm similar to DPLL[1], a change like this would >> affect performance linearly. My guess is therefore that the running >> time is reduced by approximately 5/12. Is this correct? > > There won't be any improvement if you just remove duplicates from SAT > formula. This situation is handled by picosat internally and even for > naive DPLL there is no significant influence of duplicate KNF clauses: > once you've assumed all vars in some clause, you automatically resolve > all duplicates. Exactly. This is why I've stated: it affects performance linearly. Referring to Wikipedia's pseudo-code of the algorithm: the number of calls to unit-propagate() and pure-literal-assign() drops linearly, but the recursion will stay the same. -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Optimising generated rules for SAT solving (5/12 are duplicates)
2016-11-23 17:41 GMT+01:00 Hans Petter Selasky : > GitHub wouldn't allow me to make a .diff attachment. But there's absolutely no need for doing that in the first place! :-) 1. Go to https://github.com/freebsd/pkg 2. Click 'Fork' on the top right. This will probably create a https://github.com/hselasky/pkg 3. Check out that repository using git(1), create a separate branch and commit the changes to the SAT solver. 4. Go to https://github.com/hselasky/pkg and click on 'New pull request'. 5. Fill in the form. -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Optimising generated rules for SAT solving (5/12 are duplicates)
Hi Hans, 2016-11-23 15:27 GMT+01:00 Hans Petter Selasky : > I've made a patch to hopefully optimise SAT solving in our pkg utility. Nice! Do you by any chance have any numbers that show the performance improvements made by this change? Assuming that the SAT solver of pkg(1) uses an algorithm similar to DPLL[1], a change like this would affect performance linearly. My guess is therefore that the running time is reduced by approximately 5/12. Is this correct? By the way, why attach a zip file with a diff? GitHub's pull requests are awesome! :-) [1] Davis-Putnam-Logemann-Loveland algorithm: https://en.wikipedia.org/wiki/DPLL_algorithm -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 10.03 to -current software removal?
Hi Joshua, 2016-08-22 20:54 GMT+02:00 Joshua Rogers : > /usr/local/lib/libreoffice/program/oosplash: Undefined symbol "dirname" > /usr/local/bin/transmission-gtk: Undefined symbol "dirname" This specific issue interests me, for the reason that I recently imported a new implementation of dirname(3) into libc. This error message is probably related to this work. Question: how recent is the version of FreeBSD -CURRENT to which you upgraded? Could it be the case that you installed a version that is not-so-new, but installed precompiled binary packages for 11.0 on top that depend on a newer version? Best regards, -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Socket sendmsg() porting question
2016-08-03 19:18 GMT+02:00 Lundberg, Johannes :
> Even if I set cmsg_level and cmsg_type it won't let me send it. The problem
> is having a zero length attachment on freebsd
> I can't send -1 as fd because that errors to invalid file descriptor.
Well, it makes sense. If you're attaching a message to a sendmsg()
call, it should have contents that make sense. Also, msg_controllen
should correspond with the actual space consumed by the message. Not a
single byte more. Change the logic to one of the following two.
Solution 1: Simply set msg_controllen to zero entirely, so there is no
message attached when sending.
struct cmsghdr *cmsg = CMSG_FIRSTHDR(&message);
if (fd >= 0) {
message.msg_controllen = CMSG_SPACE(sizeof(fd));
cmsg->cmsg_len = CMSG_LEN(sizeof(fd));
cmsg->cmsg_level = SOL_SOCKET;
cmsg->cmsg_type = SCM_RIGHTS;
memcpy(CMSG_DATA(cmsg), &fd, sizeof(fd));
} else {
message.msg_controllen = 0;
}
Solution 2: Send a SCM_RIGHTS message that contains no file descriptors.
struct cmsghdr *cmsg = CMSG_FIRSTHDR(&message);
cmsg->cmsg_level = SOL_SOCKET;
cmsg->cmsg_type = SCM_RIGHTS;
if (fd >= 0) {
message.msg_controllen = CMSG_SPACE(sizeof(fd));
cmsg->cmsg_len = CMSG_LEN(sizeof(fd));
memcpy(CMSG_DATA(cmsg), &fd, sizeof(fd));
} else {
message.msg_controllen = CMSG_SPACE(0);
cmsg->cmsg_len = CMSG_LEN(0);
}
Also worth mentioning:
char control[CMSG_SPACE(sizeof(int))];
That line is incorrect. The reason for this is that it may not be
sufficiently aligned. You have to make sure that the control message
buffer is aligned to at least 'struct cmsghdr', as CMSG_FIRSTHDR()
will do nothing more than return the buffer directly. Change that line
to one of the following two:
#include
alignas(struct cmsghdr) char control[CMSG_SPACE(sizeof(int))];
Or:
union {
struct cmsghdr a;
char b[CMSG_SPACE(sizeof(int))];
} control;
Best regards,
--
Ed Schouten
Nuxi, 's-Hertogenbosch, the Netherlands
KvK-nr.: 62051717
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SafeStack in base
Hi Conrad, 2016-07-28 2:02 GMT+02:00 Conrad Meyer : > The problem appears to be an upstream limitation of > -fsanitize=safe-stack: "Most programs, static libraries, or individual > files can be compiled with SafeStack as is. … Linking a DSO with > SafeStack is not currently supported." [0] I'm not sure, but I thought the reason for this is due to the fact that SafeStack uses some kind of additional library to wrap around pthread_create() to create threads that have SafeStack properly set up. If we were to actually integrate this functionality into our C runtime/pthread library to create threads with two stacks by default, then I couldn't think of a reason why it shouldn't work with DSOs. SafeStack merely depends on an additional TLS variable -- nothing else. -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r
2016-07-11 23:01 GMT+02:00 Ronald Klop : > Just downloaded the amd64 BETA1 ISO (873MB) and tried to burn a CD on > Windows 10. It complained that the ISO is too big for my 700 MB CD-r. I remember back in the days we also had a 'miniinst' CD, which was identical to 'bootonly', but at least contained the install sets to get a minimal system working. What ever happened to that? -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: console in 11.0-ALPHA4
Hi Maxim, 2016-06-28 21:14 GMT+02:00 Maxim Sobolev : > P.S. Just if somebody is interested in fixing those "fast scrolling text > turns into garbage" display issues, here is some screenshots of one of my > 11-alpha3 systems captured with a camera at 120fps. As you can see text > tears down quite badly. What happens is that rendering of vt(4) is done asynchronously. In addition to the screen contents, vt(4) keeps track of a rectangular area of the screen that needs to be updated. During every refresh, the rendering thread extracts and resets the coordinates of the rectangular area and redraws that area. It only holds a lock while extracting the rectangle's coordinates; not when redrawing. This means that if you have a lot of updates and redrawing is slow, you will get 'random' garbage on screen. Once output stops, the screen contents get refreshed one final time, making everything look all right again. -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: exports(5) no longer allows multiple paths per line?
Hi there, 2016-05-27 4:12 GMT+02:00 Ngie Cooper : > It seems like the following /etc/exports should work, but for some > odd reason specifying both paths on a single line doesn't work (I > swore it was working on a kernel/userland built in the past month, > i.e. ^/head@r297950, but I might be misremembering things). I'm not sure, but I seem to remember that an entry may only apply to a single filesystem. In your case, /tftpboot and /home/ngie are both on different filesystems, right? That's why you need two separate entries. -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: qsort() documentation
2016-04-18 15:09 GMT+02:00 Hans Petter Selasky : > On 04/18/16 14:16, Aleksander Alekseev wrote: >> I suggest also add a short description of how it was achieved >> (randomization?). > > I think the algorithm is switching to mergesort. I'll look up the paper and > add that correctly before commit. As a Dutch person, I know the answer to this. Instead of picking a fixed pivot or choosing one at random, it uses an approach called linear time median finding to find a pivot that is 'approximately median'. There are a couple of algorithms for this, but I think Bentley's qsort() uses this: https://en.wikipedia.org/wiki/Dutch_national_flag_problem -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: /bin/ls formatting broken for non-C(?) locales
Hi Baptiste, I suppose you should use the wcswidth() function somewhere to compute the visible width of the month name. Some characters may be double-width, others may have no effective width at all. -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r286615: /usr/libexec/ftpd broken!
Hi, 2015-08-11 7:40 GMT+02:00 O. Hartmann : > While ftpd daemon was working in r286590, it isn't anymore in r286615. I overlooked this: this is a pretty small set of revisions. Thanks for that. Unfortunately, if I looked at those 25 changes, I wouldn't know which one to blame... -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717 ___ 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: r286615: /usr/libexec/ftpd broken!
Hi there, 2015-08-11 10:44 GMT+02:00 O. Hartmann : > ftpd starts sometimes, sporadically, and dies somewhere in the process. > Connections to the ftpd aren't possible. Sockstat doesn't even show up a > TCP/IP > socket (21, ftp/tcp) where the daemon is supposed to listen for incoming > connection - I see only udp4 (connecting to > local_unbound/127.0.0.1:53). This is strange ... That's annoying. We should fix that. I recently made some changes to shutdown(2), but a grep reveals that ftpd doesn't call that function anywhere. Phew! The last changes made to ftpd are related to libxo. Adding marcel@, just to be sure. In the meantime, could you maybe run truss(8) over ftpd and send us the output? Thanks, -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717 ___ 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: after login through serial line, open(2) on /dev/tty hangs
2015-05-27 8:01 GMT+02:00 Matthias Apitz : > The VT102 is connected through an USB-serial adapter and getty spawns > nicely login: to /dev/cuaU0. /dev/cua* should be used to 'call out' on a TTY. They're not intended to run gettys on. Please /dev/ttyU0 instead. :-) I suspect that opening /dev/tty blocks, for the reason that the terminal you use doesn't provide any modem status lines. /dev/cua* 'works' in your case, because those device nodes ignore modem status. You can disable checking for this by using "3wire.9600" instead of "std.9600" in /etc/ttys. See gettytab(5) for more details. -- Ed Schouten ___ 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: CFR: a new __unreachable() builtin
2015-05-13 18:09 GMT+02:00 David Chisnall :
> LLVM uses this quite heavily, in a macro that expands to something equivalent
> to assert(0 && "unreachable reached!”) in debug mode and
> __builtin_unreachable() in release mode. When you’re debugging, you get
> errors if you reach unreachable code and in deployment the compiler gets a
> useful hint for optimisation.
Too bad we can't use this trick in our own assert(). You'd need to
define assert() like this:
#define assert(expr) do { \
if (!(expr)) \
__builtin_unreachable(); \
} while (0)
Unfortunately, this would cause the expression to be evaluated, which
is not allowed.
--
Ed Schouten
___
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"
[CFT] xboxfb with vt(9) (a.k.a. newcons)
Hello there, On Wed Jan 15 2014 at 1:43:56 PM, Aleksandr Rybalko wrote: > I've just committed update to xboxfb driver for vt(9). But I have no HW > to test on. So if anybody have HW and time/wish to test it, please help > me. As I also mentioned to you privately, I think it might actually be wiser to just drop Xbox support entirely. The Xbox support was a funny thing back then, but I suspect it has actually outlived its usefulness. The original Xbox only has a 733 MHz Celeron CPU, 64 MB of RAM and a 10 GB harddisk. I don't think there are that many people left who want to run FreeBSD 11 on it. Thoughts? Ed ___ 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: newcons + device.hints
Hey Vladimir, You'd better ask this question on the lists. I've added current@ and ray@to the cc. Thanks, Ed Am 11.12.2013 03:09 schrieb "Vladimir A. Noskov" : > Hello, Ed! > > I compiled FreeBSD nbw001 11.0-CURRENT FreeBSD 11.0-CURRENT # 0 r259137: > Tue Dec 10 02:57:07 MSK 2013 root @ nbw001 :/ > usr/obj/usr/home/wocson/devel/src.newcons/sys/W20131213 amd64 > This is my Toshiba laptop on CPU AMD E -450 : > > # Sysctl-a | egrep-i 'hw.machine | hw.model | hw.ncpu' > hw.machine: amd64 > hw.model: AMD E- 450 APU with Radeon (tm) HD Graphics > hw.ncpu: 2 > hw.machine_arch: amd64 > Radeon HD 6320 > > This kernel was launched in FreeBSD 10 Beta 4 (build 10 PCBSD -Stable > http://iso.cdn.pcbsd.org/10-STABLE/amd64/) > > Everything is working fine . > I have one question : Is it possible to install the OS at startup console > mode 1366x768px ? For sc was done editing device.hints. > hint.sc.0.at = "isa" > hint.sc.0.flags = "0x180" > hint.sc.0.vesa_mode = "0x11b" > > If you need any more information I will inform you . > > Thank you. > > -- > > *Vladimir A. Noskov* > ___ 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: -ffunction-sections, -fdata-sections and -Wl,--gc-sections
Hi Matthew,
2013/9/16 Matthew Fleming :
> Would it be possible to enable this only for devd, init, and clang binaries?
> Or is it a matter of enabling it for library builds that are linked
> statically with the mentioned binaries?
For it to have effect, it has to be enabled for both the libraries and
the binaries. The libraries need to be built with
-f{data,function}-sections. The binaries can also be built with those
flags, but it is actually more important to link with --gc-sections.
> Could init/devd be made smaller by
> finding out which functions they do/don't use and separating those into
> separate .c files?
Also trying to answer Tim and Adrian's questions at the same time.
I've just taken a look at init and devd to see why the difference in
size is so big:
init seems to pull in the following things:
- Sun RPC,
- XDR,
- YP,
- res_*,
- All of the jemalloc profiling/stats code,
- Some widechar functions,
- malloc-related utility functions that are not used (posix_memalign,
aligned_alloc),
- Some stdio bloat,
- All sorts of termios tc* functions.
devd seems to pull in these:
- A very big pile of C++ symbols, as libc++ places many functions in a
single file.
- jemalloc profiling/stats again,
- A big pile of pthread,
- Maybe *_l() functions, which are of course rarely used.
Honestly, I think we can assume we'll never reach the point where all
the components listed above will properly have all functions
partitioned over separate compilation units.
I suspect that it would make a lot of sense to at least enable these
build flags for our core libraries (libc, libc++, libpthread,
libcompiler_rt, libcxxrt, etc). We could also enable it on
INTERNALLIBs (libraries that are not installed into /usr/lib), as for
these libraries, it would of course not come at any cost.
Would that sound okay?
--
Ed Schouten
___
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"
-ffunction-sections, -fdata-sections and -Wl,--gc-sections
Hi all, Today I did a tiny experiment and I am not entirely sure what to do. Throw away the patch or eventually push it into the tree. GCC and Clang support the -ffunction-sections and -fdata-sections flags. Essentially, these flags force the compiler to put every function and variable in its own section. Though this will blow up the size of the .o files a lot, it has a nice advantage. In combination with ld's --gc-sections flag, it can garbage collect functions and variables during the linking phase more accurately, thereby reducing the size of the resulting binary. This will of course not work for binaries where you want to use dlsym(), so this would only be safely usable in cases where you want to do static linking. I've written a tiny patch for share/mk, crunchgen and /rescue, to set these flags, only for .o files that are used for static linking (e.g. for .a files) and when linking statically linked executables. http://80386.nl/pub/gc-sections.txt The results are interesting. On amd64: - devd suddenly becomes 500 KB in size, instead of a megabyte, - init's size drops from 900 KB to 600 KB, - clang becomes a megabyte smaller. There is a downside, though. The total size of the system becomes 8 MB larger, because the .a files in /usr/lib are a bit bigger than before. Still, I think that this can be justified: - Systems short on disk-space are typically not used for software development. As /usr/include and /usr/lib/*.a together already account for ~30% of the disk space used, these files will likely be removed on a disk-space constrained system anyway. - init and devd are so fundamental that they will likely be installed on basically any embedded FreeBSD system. Reducing the size of these binaries makes sense. - It could also reduce the size of statically linked binaries outside of the base system, depending on base libraries. What I also like about this, is that at least for the base system, it will become less important to spread out functions in libraries over separate source files, in an attempt to reduce the size of the resulting binary. We may now leave functions that are related to each other in the same source file, thus improving readability. Thoughts? -- Ed Schouten ___ 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: GCC withdraw
2013/8/25 David Chisnall : > Oh, and it's worth noting that clang, as an extension, supports using > initialiser lists to create complex values and so this particular case is > trivial to avoid if you use this feature, which you will if you create > complex numbers using the macro that the C specification introduced > specifically to avoid this case. Or even better, use the C11 CMPLX()/CMPLXF()/CMPLXL() macros, which are properly supported by FreeBSD -HEAD. -- Ed Schouten ___ 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] nvmecontrol breaks world
2013/7/2 Steve Kargl : > Could someone (this could even be me, but need approval) please > fix nvmecontrol? off_t doesn't need to be intmax_t, right? Maybe add an explicit cast? Also, the call of malloc(sb.st_size) is not really safe... -- Ed Schouten ___ 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: Infiniband OFED CLANG failing
2013/4/28 Outback Dingo : > /usr/src/contrib/ofed/usr.bin/opensm/../../management/opensm/opensm/osm_console.c:70:1: > error: use of GNU old-style field designator extension > [-Werror,-Wgnu-designator] > on: 0, delay_s: 2, loop_function:NULL}; > ^~~ This seems to be a known issue. http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/174214 I've added Garrett to the Cc, as he seems to have replied to the original ticket. -- Ed Schouten ___ 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: CURRENT: /usr/src/sbin/newfs_nandfs/newfs_nandfs.c:89:18: error: no previous extern declaration for non-static variable
Hi, 2013/4/21 O. Hartmann : > /usr/src/sbin/newfs_nandfs/newfs_nandfs.c:83:18: error: no previous > extern declaration for non-static variable > 'user_files' [-Werror,-Wmissing-variable-declarations] > struct file_info user_files[] = > ^ The following patch should fix this: http://80386.nl/pub/nandfs-warns-6.txt As of a couple of days ago, WARNS=6 requires that global variables either have an external declaration or are marked static. As newfs_nandfs only consists of a single C file, we can easily mark these variables static. In this specific case it allowed the compiler to find another peculiarity in the code, namely that the seg_segsum_size variable is unused. I'll commit this patch after I've done some testing. Thanks, -- Ed Schouten ___ 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: Is this a typo in if_tap.c?
2012/11/22 David Xu : > When I was trying to create a second tap device, kernel crashed. > Is this patch correct ? Yes, it looks okay. Eventually we should get rid of the entire unit numbering thing in if_tap and if_tun. If we would, we could remove a lot of dead code from sys/sys/conf.h and sys/kern/kern_conf.c. -- Ed Schouten ___ 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: ttydev_cdevsw has no d_purge
Hi Hans, 2012/8/9 Hans Petter Selasky : > 1) Use unrhdr. Suggested by ed. Thanks! > 2) Implement tty_set_softc() and use that when dereffing ucom unit numbers. We're getting there. Now that I think of it, if we want to go in this direction, we might as well do the following: - Simply call tty_alloc() -- not tty_alloc_mutex(). I'd rather get rid of this functionality altogether, if possible. - Use the TTY mutex to lock down the state of the ucom driver, e.g. #define ucom_lock(sc) tty_lock(sc->sc_mtx). Any thoughts? -- Ed Schouten ___ 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: ttydev_cdevsw has no d_purge
Hi Hans, 2012/8/8 Hans Petter Selasky : > Are you sure that the new softc won't be used in any callbacks when > tty_rel_gone() is called, except for tsw_free() ? Yes. Otherwise you would have already seen a kernel panic. See /sys/sys/ttydevsw.h; it has assertions on the locking. > It is like a drain state, where a unit is collected for free, and then > committed to free state when the tsw_free() is called. In the [unlocked] time > in between the unit cannot be re-used. How is this different from calling alloc/free directly? Why would it need to go through this `drain' state? -- Ed Schouten ___ 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: ttydev_cdevsw has no d_purge
2012/8/8 Hans Petter Selasky : >> I have a question regarding the changed fragment of code. Why don't you use >> unr(9) KPI to manage unit numbers ? > > Probably I could, but right now the unr interface doesn't support pending unit > free which I need for other reasons, see below. What does `pending unit free' mean? I also would prefer it if you used unr(9) -- not just here, but across the entire USB stack. > Ed: I would really like to see a custom argument for the tsw_free(), because > it only needs to know the unit number, and the xsc for UCOM is freed when this > is called and cannot be referred. Is it possible to have a separate "void *" > for the tsw_free() function? Is this something which you can implement? We could extend the TTY code to allow the softc to be changed, e.g. tty_set_softc(). This function could be called right before calling tty_rel_gone(). Still, I would prefer it if these kind of things would not be part of the API. Is there really no way the deallocation of the softc can be delayed until tsw_free() is called? Thanks, -- Ed Schouten ___ 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: ttydev_cdevsw has no d_purge
Hi Hans, 2012/8/5 Hans Petter Selasky : > When can the previous unit number be re-used? Is there a callback for this? The unit number can be reused after .tsw_free() has been called. > When can the USB serial code assume that it will not be called again and that > all callbacks are drained? The tty_rel_gone() function has to be called while holding the TTY lock. Also, all calls done by the TTY layer into the driver also hold the TTY lock and will assert that the TTY is not in the `gone' state. So you can safely assume that you will not get any driver calls as soon as tty_rel_gone() returns. I hope this helps. If you have any further questions, let me know! -- Ed Schouten ___ 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: ttydev_cdevsw has no d_purge
2012/8/1 Hans Petter Selasky : > I think the problem is like this, that in order to re-use the unit numbers for > USB serial tty devices, the USB stack needs to wait until a TTY is actually > freed, right? Else you will have a panic on creating devfs entries having the > same name. Indeed. So the USB code could simply pick a different unit number. -- Ed Schouten ___ 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: ttydev_cdevsw has no d_purge
2012/8/3 Julian Elischer : > they would only do that if they were refering to the node BY NAME. Which is exactly what a lot of software does when interacting with TTYs. -- Ed Schouten ___ 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: ttydev_cdevsw has no d_purge
2012/8/2 Julian Elischer : > I think that the /dev/entries can (and SHOULD) go away when the hardware > goes away and even be re-used. But here's the point. TTYs are used in a different way than other device nodes. Regular device nodes are simply opened by a set of independent process (e.g. dd if=/dev/da0, a music player opening /dev/dsp, etc). TTYs are used by a set of processes that share a weak relationship, namely all belonging to the same login session. Things *really* break if you were to forcefully remove a TTY device node and replace it by another TTY. Even for physical devices it would be really bad to do. Consider a system that has two USB to serial converters that are used for interactive login sessions. One is plugged in, the other one isn't. If you unplug one device and plug in the other, you never want the processes from the one login session to start interacting with the other device. Also, applications relying on the user accounting database (utmpx) will start to behave non-deterministically then. Do we really want biff and wall to write stuff to random TTYs? Whether or not the TTY is a pseudo-terminal or not is completely irrelevant in my opinion. -- Ed Schouten ___ 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: ttydev_cdevsw has no d_purge
Hi Kostik, 2012/8/1 Konstantin Belousov : > I would blame tty subsystem rather then USB subsystem. The d_purge > method of the ttydev_cdevsw is not implemented, but it is the only > measure that can break the deadlocks like the one I described. The > d_purge shall wake up threads sleeping inside devsw methods, which was > specifically added to notify driver about device gone events. I guess d_purge was added quite recently, right? In the current design, the USB code must call into tty_gone() to report that the TTY is no longer associated with an actual device. This shall result in all threads blocking on a TTY to be woken up. Also, it will prevent any further calls into the USB code by the TTY layer. Still, if the processes are not actually interacting with the TTY (e.g. sleep 10, just waiting for nanosleep() to return), then there is no way the TTY code can actually garbage collect the TTY. It must stay there. Removing the actual TTY would introduce a whole bunch of races and unwanted behaviour. Applications may cache the pathname to the TTY. If the pathname were to be reused by another device, apps would start writing to random TTYs. So that's why TTYs may still stick around in devfs, even though the device underneath went missing. The driver simply calls tty_gone() and leaves the TTY alone. It will die eventually, but you shouldn't wait for it to happen. Still, I seem to remember the USB code does something weird. I think the USB serial driver tries to block until the TTY is actually destroyed. This is a bug, which I've discussed with hselasky@ numerous times. It simply must not do that. -- Ed Schouten ___ 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: Changes to sbin/init/init.c (r233944) makes x11/xdm impossible to start from /etc/ttys
Hi Oliver, * O. Hartmann , 20120413 19:09: > Hope the discussion is going on and will make the problem go away. It is > still present and bothering ... Sorry about taking so long to respond. I've been very busy the last week. I just got xdm working on a stock FreeBSD HEAD install just now. Is there a way for me to reproduce? -- Ed Schouten WWW: http://80386.nl/ pgpOIEZIlv1x0.pgp Description: PGP signature
Re: Changes to sbin/init/init.c (r233944) makes x11/xdm impossible to start from /etc/ttys
Hi Oliver, * O. Hartmann , 20120410 11:37: > Reverting init.c back to its previous state seems to make the error go away. Sorry about that. I added the O_NONBLOCK to prevent init(8) from possibly getting stuck if the TTY used by /dev/console were to misbehave by not setting CLOCAL. It seems we can't do this reliably at all, so I guess I'd better just revert the code like so: http://80386.nl/pub/init.txt I'll commit the patch to SVN after I have discussed it wtih kib@. Thanks for reporting! -- Ed Schouten WWW: http://80386.nl/ pgpIjmJRtiOFJ.pgp Description: PGP signature
Re: virtio device unknown
Hi Kim, * Kim Culhan , 20120318 14:37: > Compiling a kernel with: > > device virtio > device virtio_pci > > returns: > > config: Error: device "virtio" is unknown > config: Error: device "virtio_pci" is unknown If I remember correctly, the infrastructure to build the virtio drivers into the kernel has not been added to the source tree yet. It seems you can only use the kernel modules. Good luck, -- Ed Schouten WWW: http://80386.nl/ pgpReYn8n8pmF.pgp Description: PGP signature
Re: installworld: posix_memalign
Hi, * Monthadar Al Jaberi , 20120117 18:17: > But now I get another error when installworld I suspect something unrelated to my change is the culprit. Can you make sure your source tree is not modified, for example by checking out using a different cvsup mirror? Thanks, -- Ed Schouten WWW: http://80386.nl/ pgphvr7s3q0A2.pgp Description: PGP signature
Re: Small usr.bin/Makefile patch to remove a reference to wtmpcvt
Hi Jos, * Jos Backus , 20120116 21:26: > This directory no longer exists so the reference should be removed as it > breaks the build. Could it be possible that you checked out the source tree (from CVS) at an unlucky moment in time? It seems I did remove it properly: http://svnweb.freebsd.org/base/head/usr.bin/Makefile?r1=229997&r2=230060 -- Ed Schouten WWW: http://80386.nl/ pgpXhZ4MUKuku.pgp Description: PGP signature
Re: installworld: posix_memalign
Hi Monthadar, * Monthadar Al Jaberi , 20120116 18:48: > I updated my source tree to lastest and buildworld and buildkernel > without error. but installworld gives this error: > > install: posix_memalign.3.gz: No such file or directory > > checking the the log I see there where some changes done 6 days ago > for this file /head/lib/libc/stdlib/Makefile.inc > > should this line inside Makefile.inc: > > MLINKS+=aligned_alloc.3 posix_memalign.3 > > be changed to > > MLINKS+=aligned_alloc.3 Are you sure about this? Filenames provided in MLINKS are always provided in pairs. You specify which file needs to be linked to the other. So the aligned_alloc man page needs to be linked to posix_memalign. What happens if you remove your obj-directory before running make buildworld/installworld? Thanks, -- Ed Schouten WWW: http://80386.nl/ pgpArt6BCO60F.pgp Description: PGP signature
Re: [rfc] removing/conditionalising WERROR= in Makefiles
* Philip Paeps , 20111227 02:04: > Wouldn't it be better to set WARNS=x rather than WERROR=? Not entirely related to the discussion, but worth mentioning: WARNS is only used by -- not . -- Ed Schouten WWW: http://80386.nl/ pgpmcXP0kSzD8.pgp Description: PGP signature
[Resolved] GCC 4.6 compilation problems w.r.t. static_assert
* Ed Schouten , 20111228 19:10: > Hmmm... This seems to apply to my changes. I will look into this > tomorrow. Thanks for the report! Just to clarify, as mentioned earlier in this thread, the linking problems problems are not related by my C11 patches, as they are only part of HEAD. It seems they were caused due to local configuration problems and have been resolved. The GCC 4.6 compilation problem on HEAD was caused by one of my changes. Please update your system to r228955 or later. Thanks for reporting. -- Ed Schouten WWW: http://80386.nl/ pgp6DOioT1g4R.pgp Description: PGP signature
Re: /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a: could not read symbols: Bad value
* Rainer Hurling , 20111228 17:31: > error: macro "_Static_assert" passed 3 arguments, but takes just 2 > In file included from > /usr/ports/lang/gcc46/work/gcc-4.6-20111209/libstdc++-v3/include/precompiled/stdc++.h:103:0: Hmmm... This seems to apply to my changes. I will look into this tomorrow. Thanks for the report! -- Ed Schouten WWW: http://80386.nl/ pgpgFV4VlXdVC.pgp Description: PGP signature
Re: ee (easy editor) bugged on 9.0?
Hello Jason, * Jason Edwards , 2027 22:15: > Thanks for the impressive list of advantages! There's just one > non-critical issue I'd like to address regarding the use of xterm > terminal type. > > When using cons25 terminal, the dialog menus (drawn using > devel/cdialog and `make config` in portstree as well) are using smooth > lines to draw boxes and stuff. > > But when using xterm terminal, those lines are replaced by 'dashed' > lines like - - - - - instead of a smooth line without whitespace in > between. When doing the same via SSH login, the lines are smooth with > xterm type. So this issue appear to be limited to the console in > combination with xterm terminal type. > > Is there a way to use xterm but still allow cdialog to draw smooth > lines on the console? Unfortunately, this is actually a workaround for a problem that existed all along, even before we switched to TERM=xterm. It's not beautiful, but needed. When using TERM=cons25, ncurses applications simply print certain bytes to do the box drawing, namely these ones: http://en.wikipedia.org/wiki/Code_page_437#Standard_code_page This means that if you load a different font file into the console driver that uses a different character set (e.g. ISO-8859-1), you get all sorts of math characters and diacritics instead of the box drawing characters. With TERM=xterm, this is essentially solved, because box drawing can be performed using character set independent escape sequences (using ^N and ^O), but the problem is that syscons does not know which glyphs in the font file correspond with the box drawing characters. There are two ways to solve this: - Extend the font file format to include a mapping table of box drawing characters to glyph indices, - Patch syscons to just print +-| instead of the box drawing characters. The first option would fix it properly, but in my opinion it's not worth the effort, because time should be spent to just get Unicode working. The terminal emulator already supports Unicode internally and even remaps box drawing characters to Unicode. Get Unicode working and you fix the box drawing issue for free. This is why I have chosen the second option. If you really miss the box drawing characters, you can revert SVN revision 203659. Do keep in mind that it effectively breaks support for custom fonts/character sets. I think box drawing does work when you compile your kernel with TEKEN_UTF8 (poor mans UTF-8 support), but please don't attempt to load any fonts then. Best regards, -- Ed Schouten WWW: http://80386.nl/ pgpuueQ3Esoka.pgp Description: PGP signature
Re: ee (easy editor) bugged on 9.0?
* Ed Schouten , 2023 19:11: > There are two reasons why I changed the default terminal emulator to be > xterm-like, instead of conforming to cons25: Errr... for large values of two. -- Ed Schouten WWW: http://80386.nl/ pgpifNuiJHbAs.pgp Description: PGP signature
Re: ee (easy editor) bugged on 9.0?
Hi Jason, * Jason Edwards , 2022 21:56: > I wonder: is cons25 bugged or simply obsolete? Not that I want to keep > cons25; just being curious. There are two reasons why I changed the default terminal emulator to be xterm-like, instead of conforming to cons25: - It is more compatible. Not all operating systems have proper cons25 entries in their termcap/terminfo, meaning it is practically impossible to SSH to one of those systems and do your work properly. Also, there are many devices (e.g. Cisco/HP switches) that don't offer a lot of flexibility with respect to terminal handling. By using an xterm-style emulator, this is all solved, because xterm is pretty much compatible with VT100 and friends. - It is more bandwidth efficient. cons25-like terminals do not (have to) support more advanced features like scrolling regions. This means for example that if you use applications where only a portion of the screen scrolls (e.g. irssi, mutt), it has to redraw that entire portion of the screen, instead of being able to simply scroll that independent region, without affecting the rest of the display contents. This is of course no problem when running applications locally, but it does have its advantages when SSHing to another system. - It is more future proof. There are many implementations of xterm-like terminals that demonstrate that it's not hard to get (a sane subset of) UTF-8 and 256 colors working. Things like that are simply not available for cons25. As people pointed out, if you still want to keep on using TERM=cons25 (not advised, though), you _MUST_ either compile your kernel with TEKEN_CONS25 or run vidcontrol -T cons25. This is due to the fact that cons25-like terminals are incompatible with xterm-like terminals. For example: - With xterm, ^N and ^O are used to switch character maps, while with cons25, they render a music note and star symbol. - With xterm, processing backspace while the cursor is at the first column of the screen does nothing, while cons25 performs reverse line wrapping. - With xterm, ^L is interpreted as a newline, while with cons25, it clears the entire screen. - With xterm, line wrapping of the cursor on a display of n columns wide is only performed when printing the n+1'th character, while cons25 already does this after the n'th character. Effectively, this makes it very hard to print a character in the lower righthand corner of the screen. One of these incompatibilities is likely what caused the problems you experienced when you ran ee(1) without updating /etc/ttys accordingly. -- Ed Schouten WWW: http://80386.nl/ pgpjoclhMhX6j.pgp Description: PGP signature
Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers
Hi Robert, * Robert Millan , 2022 18:53: > +#undef __FreeBSD_kernel__ > +#define __FreeBSD_kernel__ So why not remove the #undef and not let the compiler define it at all? -- Ed Schouten WWW: http://80386.nl/ pgpNzLA7HWcFI.pgp Description: PGP signature
Re: [head tinderbox] failure on powerpc64/powerpc
* FreeBSD Tinderbox , 2006 20:28: > atrun.o:(.got+0x28): undefined reference to `effective_uid' > atrun.o:(.got+0x30): undefined reference to `effective_gid' > atrun.o:(.got+0x40): undefined reference to `real_gid' > atrun.o:(.got+0x48): undefined reference to `real_uid' Sorry about that. Should be fixed now! -- Ed Schouten WWW: http://80386.nl/ pgp7bdMrUzqTc.pgp Description: PGP signature
Re: FreeBSD 9.0 BETA1 build kernel
* Ruslan Yakovlev , 20111028 17:45:
> nvenetlib.o:(.bss+0x0): multiple definition of `array'
>
> tws_services.o:(.data+0x0): first defined here
G! $#(*@!&(*!@&#
I think you can work around this by removing either nve or tws.
I guess problems like these are mainly caused by the fact that we often
forget to mark global variables as static, even though they ought to be.
If only GCC/Clang had a warning for that...
--
Ed Schouten
WWW: http://80386.nl/
diff --git a/contrib/llvm/tools/clang/include/clang/Basic/DiagnosticSemaKinds.td b/contrib/llvm/tools/clang/include/clang/Basic/DiagnosticSemaKinds.td
index 97414f2..1306846 100644
--- a/contrib/llvm/tools/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/contrib/llvm/tools/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -2273,6 +2273,9 @@ def note_sentinel_here : Note<
def warn_missing_prototype : Warning<
"no previous prototype for function %0">,
InGroup>, DefaultIgnore;
+def warn_missing_variable_declaration : Warning<
+ "no previous extern declaration for non-static variable %0">,
+ InGroup>, DefaultIgnore;
def err_redefinition : Error<"redefinition of %0">;
def err_definition_of_implicitly_declared_member : Error<
"definition of implicitly declared %select{default constructor|copy "
diff --git a/contrib/llvm/tools/clang/lib/Sema/SemaDecl.cpp b/contrib/llvm/tools/clang/lib/Sema/SemaDecl.cpp
index 9d91a48..9a5fe21 100644
--- a/contrib/llvm/tools/clang/lib/Sema/SemaDecl.cpp
+++ b/contrib/llvm/tools/clang/lib/Sema/SemaDecl.cpp
@@ -4002,6 +4002,11 @@ void Sema::CheckVariableDeclaration(VarDecl *NewVD,
Previous.addDecl(Pos->second);
}
+ if (Previous.empty() && NewVD->getStorageClass() == SC_None &&
+ NewVD->hasGlobalStorage())
+Diag(NewVD->getLocation(),
+ diag::warn_missing_variable_declaration) << NewVD;
+
if (T->isVoidType() && !NewVD->hasExternalStorage()) {
Diag(NewVD->getLocation(), diag::err_typecheck_decl_incomplete_type)
<< T;
pgpn88f9sPMxm.pgp
Description: PGP signature
Re: Upgrade from source to RC1: problems with /etc : lost users and dbus
* Tom Evans , 20111027 13:06: > I have had this happen before, the PEBKAC. When running mergemaster, > it will prompt you to install new passwd, master.passwd and group > files - if you have added local users you must not say yes to this, > you must either merge the changes in or keep your local one. It would have been so awesome if our /etc/master.passwd and /etc/group included an #include directive. -- Ed Schouten WWW: http://80386.nl/ pgpWLofpb8j4g.pgp Description: PGP signature
Re: Not setting TERM explicitly wraps commands at 80 columns with nested shells in xterms using sh + bash?
* Garrett Cooper , 20111021 09:00:
> On Thu, Oct 20, 2011 at 11:59 PM, Ed Schouten wrote:
> > Hi Garrett,
> >
> > * Garrett Cooper , 20111021 08:40:
> >> If I fire up an xterm without setting TERM={ansi,vt100,xterm},
> >> [...]
> >
> > So what's the idea behind this? Why not just set TERM properly?
>
> It is set properly though -- that's the confusing part:
>
> $ echo $TERM
> xterm
Oh, okay. So you mean "If I fire up an xterm without changing the
default TERM, [...]", right?
Can you check whether `stty size' does return the correct numbers? That
way we can determine if it's a problem in xterm, your shell (or maybe
the kernel). Thanks!
--
Ed Schouten
WWW: http://80386.nl/
pgpjm8lpdY66F.pgp
Description: PGP signature
Re: Not setting TERM explicitly wraps commands at 80 columns with nested shells in xterms using sh + bash?
Hi Garrett,
* Garrett Cooper , 20111021 08:40:
> If I fire up an xterm without setting TERM={ansi,vt100,xterm},
> [...]
So what's the idea behind this? Why not just set TERM properly?
--
Ed Schouten
WWW: http://80386.nl/
pgphKqlDvo4XU.pgp
Description: PGP signature
Re: [PATCH] Prepend timestamp in msgbuf
Ah, missed something. > + getnanouptime(&ts); > + err = snprintf(buf, sizeof buf, "[%zd.%.6ld] ", > + ts.tv_sec, ts.tv_nsec / 1000); It seems we also have a getmicrouptime(), which returns a struct timeval. Also a more general question: is it actually safe to call getnanouptime() here? This code gets executed from an arbitrary context, right? -- Ed Schouten WWW: http://80386.nl/ pgpOeBagOuQDB.pgp Description: PGP signature
Re: [PATCH] Prepend timestamp in msgbuf
Hi Arnaud!
* Arnaud Lacombe , 20111017 22:41:
> + buf[0] = '\0';
> + getnanouptime(&ts);
> + err = snprintf(buf, sizeof buf, "[%zd.%.6ld] ",
> + ts.tv_sec, ts.tv_nsec / 1000);
What's the use of buf[0] = '\0'? snprintf() will overwrite it anyway,
right? Also. please use %jd and cast ts.tv_sec to intmax_t. The size of
time_t and size_t are independent. As far as I know, you should be able
to use a 64-bit time_t on i386 by simply changing the typedef and
recompiling everything.
> + bufp = buf;
> + while (*bufp != '\0') {
> + __msgbuf_do_addchar(mbp, seq, *bufp);
> + bufp++;
> + }
It would be nicer to write this as follows:
for (bufp = buf; *bufp != '\0'; bufp++)
__msgbuf_do_addchar(mbp, seq, *bufp);
> - intmsg_needsnl; /* set when newline needed */
> + uint32_t msg_flags;
Why change this to uint32_t instead of leaving it the way it is (or
changing it to unsigned int)? Even though they are likely to be equal in
size, there is no reason why msg_flags must be 32 bits. :-)
--
Ed Schouten
WWW: http://80386.nl/
pgpFwZRV69K8d.pgp
Description: PGP signature
Re: [RFC] Prepend timestamp in msgbuf
* Garrett Cooper , 20111017 21:38: > time_t maps to int32_t on i386 and int64_t on amd64 (at least), so > you should be able to use "%zd" in the format string as the type is > variable width depending on the architecture. Yuck. Why not cast it to intmax_t and print it using %jd? -- Ed Schouten WWW: http://80386.nl/ pgpgMKrnZfrX8.pgp Description: PGP signature
Re: MPSAFE tty and lastcomm output
Hi , * poyop...@puripuri.plala.or.jp , 20111011 14:20: > It looks stored accounting information is correct, but lastcomm failed > to represent device name gently after it has been destroyed. Yes, exactly. Our struct acct uses a dev_t to store the controlling TTY. This is obviously completely broken on 8+, because we garbage collect pseudo-terminals. Still, one could argue it has always been broken, because even before the new TTY layer it would break when unplugging USB-to-serial converters or performing a reboot. I think the only way to fix this, is by updating the acct structure to write a string representation of the device name. Best regards, -- Ed Schouten WWW: http://80386.nl/ pgpqyFabywpmx.pgp Description: PGP signature
Re: Experiences with FreeBSD 9.0-BETA2
* Greg Miller , 20111008 22:47: > I've never gotten around to reporting this until this thread came up, > but I've found that GNU Emacs has tons of problems with text > disappearing on the console. Just moving the cursor to the start of a > long line and holding down the right-arrow key is enough to cause many > of the characters to disappear. Can you try applying the patch I mentioned previously? If it doesn't fix this issue, please let me know, so I can get it fixed in 9.0. Thanks! -- Ed Schouten WWW: http://80386.nl/ pgp25SMDbLIhI.pgp Description: PGP signature
Re: Experiences with FreeBSD 9.0-BETA2
Hi Brett, * Brett Glass , 20111007 15:40: > The patch is an improvement. Not assuming that tabs blank the underlying > cells is definitely a help. But it does not fix all of the artifacts. Just let me know what's broken specifically. So what keys to press when I start jove to reproduce it. I'm really not familiar with Emacs. > It might be a good idea to review the "xterm" termcap entry, capability > by capability, to make sure that syscons conforms to each one. As the > author of a very exacting vt100 emulator (I wrote Borland's "Turbo Terminal" > back in the 80s), I know just how quirky, poorly documented, and buggy some > terminals can be. I had to emulate every strange behavior and bug in the > vt100 without access to the source code that the embedded CPU was running. > In general, the behaviors that cause the most problems are wrapping and > unwrapping text, writing past the edges of the screen, positioning near > the edges of the screen, and manipulating the top and bottom lines. The > vt100, for example, would not scroll when you wrote the last character on > a line, but would then scroll if you entered one character after that > without executing a command that repositioned the cursor. It would also > ignore linefeeds after automatic scrolling (due to DEC's convention that > text files have both a CR and an LF at the end of each line rather than > just an LF as in UNIX). If you'd like, I can try to come up to speed on > the code and help to debug, but I do not use X and so have no experience > with its default terminal emulator; I'd have to study that as well. Well, apart from small bugs here and there, it should be pretty conformant already, especially when compared to various graphical terminal emulators (e.g. GNOME terminal). For example, it passes quite a large number of tests from vttest. A nice thing about the terminal emulator is that it can be compiled in userspace as well: cd /sys/teken/libteken make make install clean cd ../demo make ./teken_demo This will spawn a demo application that renders the terminal using ncurses. -- Ed Schouten WWW: http://80386.nl/ pgpeZIDMWO07w.pgp Description: PGP signature
Re: Experiences with FreeBSD 9.0-BETA2
Hi Brett, * Brett Glass , 20111007 15:18: > Among other things, you'll see portions of lines vanish from the > screen while you're editing, until you hit ^L (the EMACS command to > refresh the screen) a couple of times. Yeah, that should be fixed now. I just ran `jove /etc/ttys', moved the cursor around and indeed saw some lines disappear. -- Ed Schouten WWW: http://80386.nl/ pgpb4pOiu56IP.pgp Description: PGP signature
Re: Experiences with FreeBSD 9.0-BETA2
* Ed Schouten , 20111007 13:02: > It should be xterm, since syscons now uses an xterm-style terminal > emulator. I have never used jove before, so what should I do to > reproduce this? After some tinkering, I think I know why it breaks. I thought that when xterm processes a tab, it blanks the underlying cells. This doesn't seem to be the case, so I've fixed that in r226099. Would it be possible for you to test HEAD r226099 or apply this patch to your source tree? http://svnweb.freebsd.org/base/head/sys/teken/teken_subr.h?r1=223574&r2=226099&view=patch If so, there's a fair chance I can get it squeezed into 9.0. Thanks! -- Ed Schouten WWW: http://80386.nl/ pgpM0Odm7ocde.pgp Description: PGP signature
Re: Experiences with FreeBSD 9.0-BETA2
* Brett Glass , 20110926 02:52: > 1) The jove editor worked strangely because, in /etc/ttys, the > terminal type was set to "xterm" instead of "cons25" by default. (I > do not run a GUI on servers, so of course there will not be an > xterm.) As a result, parts of lines kept vanishing from under my > cursor. However, even after I modified /etc/ttys, I still saw some > screen artifacts. The maintainer of the console driver should > probably check it to see whether its termcap entry needs changing. It should be xterm, since syscons now uses an xterm-style terminal emulator. I have never used jove before, so what should I do to reproduce this? -- Ed Schouten WWW: http://80386.nl/ pgpddPBEyFnB8.pgp Description: PGP signature
Re: which "include" being used?
* Garrett Cooper , 20110921 04:34: > I'd unpack a tarball from the most recent release. It's the easiest > way to fix things :).. Well, sometimes this is sufficient: cd /usr/src/include make install clean That way you'll at least get the default system headers back. -- Ed Schouten WWW: http://80386.nl/ pgpZsLqAteBT9.pgp Description: PGP signature
Re: Serial Port Configuration does not work
* Boris Samorodov , 20110912 07:33: > Thanks Jilles! That did it: Thanks for reporting/testing. Fixed in r225506! -- Ed Schouten WWW: http://80386.nl/ pgp9eg7BIlocP.pgp Description: PGP signature
Re: ahci(4) breaks on MSI X58 Pro-E
* Ed Schouten , 20110805 20:53: > The day before yesterday I upgraded a server of mine at Hetzner to > FreeBSD 9. It seems to use an MSI X58 Pro-E motherboard, having an ICH10 > SATA-controller. > > It seems that under high load, I get timeouts on the SATA controller. It > seems disabling MSI has no effect. Unfortunately it's a sort-of > production system, so I can't do a lot of testing with it and I also > don't have any hands-on console access. False alarm. One of the hard disks of the server died, not long after I upgraded to 9. They replaced the disk and the system runs fine again. It should be noted that the ahci(4) driver made the system hang on timeouts, whereas the ata(4) driver already observed timeouts during startup and disabled the channel entirely. This allowed me to properly boot with a single disk. -- Ed Schouten WWW: http://80386.nl/ pgpKBGGUx8dRj.pgp Description: PGP signature
Re: svn commit: r224659 - head/etc
Hi Doug, * Doug Barton , 20110806 02:07: > The other issue is that due to the way that mergemaster works by default > users who have existing /etc/nsswitch.conf files (which should be pretty > close to 100%) won't see this change because it doesn't affect the > $FreeBSD$ tag. If we decide to keep things this way then I would suggest > adding a comment to that file so that it will get picked up. You can work around this by doing a forced commit with SVN: - Add some whitespace to the file - Run svn commit - Remove the whitespace while the editor is open This will bump the $FreeBSD$ without changing its file contents. > However, I would much rather see us actually change the default file. > Users who are going to enable nis will already know that this file needs > to be tweaked, and by using more sensible defaults we'll be more > relevant to the majority of our userbase. So I propose the attached > (along with reverting your change obviously). I'm fine either way. Feel free to commit it (after re approval). :-) -- Ed Schouten WWW: http://80386.nl/ pgpfzCgwN13G4.pgp Description: PGP signature
ahci(4) breaks on MSI X58 Pro-E
Hi all, The day before yesterday I upgraded a server of mine at Hetzner to FreeBSD 9. It seems to use an MSI X58 Pro-E motherboard, having an ICH10 SATA-controller. It seems that under high load, I get timeouts on the SATA controller. It seems disabling MSI has no effect. Unfortunately it's a sort-of production system, so I can't do a lot of testing with it and I also don't have any hands-on console access. Is there anyone out there who has a system at home that also has an X58 motherboard and can test latest HEAD to see whether it is a recurring problem? I've attached the output of dmesg for now. Disabling the ahci driver and using ata seems to work. -- Ed Schouten WWW: http://80386.nl/ Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-BETA1 #0 r+4f5f78a: Wed Aug 3 10:42:02 CEST 2011 e...@hertog.hoeg.nl:/usr/obj/export/pub/src/sys/HERTOG amd64 CPU: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz (2673.36-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x106a5 Family = 6 Model = 1a Stepping = 5 Features=0xbfebfbff Features2=0x98e3bd AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 8594128896 (8196 MB) avail memory = 8233840640 (7852 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: <7522MS A7522800> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0 irqs 0-23 on motherboard acpi0: <7522MS A7522800> on motherboard acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, bff0 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 ACPI Warning: Incorrect checksum in table [OEMB] - 0xD0, should be 0xCF (20110527/tbutils-282) cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pcib2: at device 3.0 on pci0 pci2: on pcib2 vgapci0: port 0xcc00-0xcc7f mem 0xfa00-0xfaff,0xd000-0xdfff,0xf800-0xf9ff irq 16 at device 0.0 on pci2 pcib3: at device 7.0 on pci0 pci3: on pcib3 pci0: at device 20.0 (no driver attached) pci0: at device 20.1 (no driver attached) pci0: at device 20.2 (no driver attached) pci0: at device 20.3 (no driver attached) pci0: at device 26.0 (no driver attached) pci0: at device 26.1 (no driver attached) pci0: at device 26.2 (no driver attached) pci0: at device 26.7 (no driver attached) pcib4: irq 17 at device 28.0 on pci0 pci4: on pcib4 pcib5: irq 17 at device 28.4 on pci0 pci6: on pcib5 re0: port 0xe800-0xe8ff mem 0xfbeff000-0xfbef,0xf6ff-0xf6ff irq 16 at device 0.0 on pci6 re0: Using 1 MSI-X message re0: Chip rev. 0x3c00 re0: MAC rev. 0x0040 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 40:61:86:be:cd:da pci0: at device 29.0 (no driver attached) pci0: at device 29.1 (no driver attached) pci0: at device 29.2 (no driver attached) pci0: at device 29.7 (no driver attached) pcib6: at device 30.0 on pci0 pci7: on pcib6 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0xb000-0xb007,0xac00-0xac03,0xa880-0xa887,0xa800-0xa803,0xa480-0xa49f mem 0xf7ffa000-0xf7ffa7ff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.20 with 6 3Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd0: [GIANT-LOCKED] hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer
Re: nsswitch.conf <-> WITHOUT_NIS
* Ed Schouten , 20110804 19:30:
> But on the other hand, nsswitch.conf says it will default to `nis'
> anyway. So I suspect the lines shouldn't be removed, but changed to
> `files', right? Maybe we should consider modifying the configuration
> file accordingly?
After reading some more manpages and doing some testing, it seems we
must remove the _compat: lines and change the compat source to files.
Any comments on the following patch?
--- etc/Makefile
+++ etc/Makefile
@@ -256,6 +256,10 @@ distribution:
${DESTDIR}/boot/device.hints
.endif
.endif
+.if ${MK_NIS} == "no"
+ sed -i "" -e '/_compat:/d' -e 's/compat/files/' \
+ ${DESTDIR}/etc/nsswitch.conf
+.endif
distrib-dirs:
mtree -eU ${MTREE_FOLLOWS_SYMLINKS} -f ${.CURDIR}/mtree/BSD.root.dist
-p ${DESTDIR}/
--
Ed Schouten
WWW: http://80386.nl/
pgppwoSLXlx8G.pgp
Description: PGP signature
nsswitch.conf <-> WITHOUT_NIS
Hi folks,
I just noticed cron doesn't work nicely when running a system built
without NIS, since it won't allow you to send emails:
| Aug 4 09:45:00 palm postfix/sendmail[12217]: fatal: www(80): No recipient
addresses found in message header
| Aug 4 10:45:00 palm postfix/sendmail[12827]: fatal: www(80): No recipient
addresses found in message header
| Aug 4 11:45:00 palm postfix/sendmail[13515]: fatal: www(80): No recipient
addresses found in message header
| Aug 4 12:45:00 palm postfix/sendmail[14786]: fatal: www(80): No recipient
addresses found in message header
| Aug 4 13:45:01 palm postfix/sendmail[15409]: fatal: www(80): No recipient
addresses found in message header
| Aug 4 14:45:00 palm postfix/sendmail[18896]: fatal: www(80): No recipient
addresses found in message header
According to various sources, this can be fixed by properly
configuration your nsswitch.conf. Now my question is, how should
nsswitch.conf be adjusted? The src.conf manual page says this:
If set, you might need to adopt your nsswitch.conf(5) and remove
‘nis’ entries.
That sort of seems to imply that you can just remove these lines:
group_compat: nis
passwd_compat: nis
services_compat: nis
But on the other hand, nsswitch.conf says it will default to `nis'
anyway. So I suspect the lines shouldn't be removed, but changed to
`files', right? Maybe we should consider modifying the configuration
file accordingly?
--- etc/Makefile
+++ etc/Makefile
@@ -256,6 +256,9 @@ distribution:
${DESTDIR}/boot/device.hints
.endif
.endif
+.if ${MK_NIS} == "no"
+ sed -i "" -e 's/nis/files/' ${DESTDIR}/etc/nsswitch.conf
+.endif
distrib-dirs:
mtree -eU ${MTREE_FOLLOWS_SYMLINKS} -f ${.CURDIR}/mtree/BSD.root.dist
-p ${DESTDIR}/
--
Ed Schouten
WWW: http://80386.nl/
pgpQL4OyODno2.pgp
Description: PGP signature
Re: [Patch] [regression] libvgl and r197330 (kbd)
* John Baldwin , 20110717 03:22: > I just asked the kFreeBSD folks to test Ed's patch and it does restore the > ABI. Ed, can you commit this patch as it's been successfully tested now? Sure. Done! -- Ed Schouten WWW: http://80386.nl/ pgpFqJR1d0Blj.pgp Description: PGP signature
Re: llimport(8): Import lastlog into utmpx
* Doug Barton , 20110603 23:10: > On 06/03/2011 14:07, Ed Schouten wrote: > >the reason why I picked the current > >approach, is because I don't want to cause people to get confused when > >they upgrade to 9.0, to discover that their lastlog database is > >`missing'. > > Understood, but in my mind that's a release notes issue. That sounds like a good idea. I'll see what I can do. Thanks! -- Ed Schouten WWW: http://80386.nl/ pgpJZprgytqdq.pgp Description: PGP signature
Re: llimport(8): Import lastlog into utmpx
Hi Doug, * Doug Barton , 20110603 22:57: > FWIW I'm not enthusiastic about either option. I definitely don't > think an rc.d script is desirable, since it would be run at every > boot for what (if I understand it correctly) is a one-time thing. > More or less the same argument applies to adding this to mergemaster. True. I just looked at mergemaster, but adding it to mergemaster could be unreliable. Say, you're running mergemaster on a different destdir, it would call llimport from the host system, meaning it uses the user database (and byte order) of the host, instead of the target. > In my mind the best way to handle this would be to add it to tools/ > and let users who need it access it that way. But perhaps I'm missing > something? I could do that as well, but the reason why I picked the current approach, is because I don't want to cause people to get confused when they upgrade to 9.0, to discover that their lastlog database is `missing'. Groetjes, -- Ed Schouten WWW: http://80386.nl/ pgptNF6UbCr4L.pgp Description: PGP signature
Re: llimport(8): Import lastlog into utmpx
Hi Garrett, * Garrett Cooper , 20110603 22:47: > Is this a one time change? If so, wouldn't it make more sense to > put this into mergemaster(8) instead of rc(5)? Good point. I hadn't thought about that. I'll take a look. -- Ed Schouten WWW: http://80386.nl/ pgpPqpOBLzIvU.pgp Description: PGP signature
llimport(8): Import lastlog into utmpx
Hi all, I think not long after I replaced utmp with utmpx, I got requests to add utilities to convert the old utmp databases to the new formats. I added wtmpcvt(1) for /var/log/wtmp*, but I didn't add any tools for the other databases. Even though it's a bit overdue (more than one year later?), I think it wouldn't be a bad idea to add a utility to import lastlog for people who are going to upgrade from 7.x/8.x to 9.0. I've written a utility called llimport(8), which imports entries from lastlog into utx.lastlogin for users which do not already have an entry in the latter. I've also added an rc-script, which executes llimport when /var/log/lastlog is present and renames the old database to /var/log/lastlog.old. Any objections if I commit the following patch to HEAD one of these days? I will remove it from HEAD not long after we release 9.0, since an upgrade from 8.x to 10.x should go through 9.x anyway. http://80386.nl/pub/llimport.txt It would be nice if someone could look at the rc script. I think it should be okay, but it's not a part of the tree I'm familiar with. -- Ed Schouten WWW: http://80386.nl/ pgpDelehwOm1f.pgp Description: PGP signature
Re: Keymaps in X11 and consoles should be the same with TEKEN_XTERM in the kernel.
* crocket , 20101113 13:52: > TEKEN_XTERM turns on xterm mode. > I compiled a kernel with TEKEN_XTERM, and changed cons25 to xterm in > /etc/ttys. > > When I executed vim on a console, the keyboard acted weirdly. Keep in mind that this list is supposed to discuss FreeBSD -CURRENT; not FreeBSD 8.x. Please don't use xterm mode on FreeBSD 8. It doesn't come with any support whatsoever. -- Ed Schouten WWW: http://80386.nl/ pgp07pH8M2FcF.pgp Description: PGP signature
Re: MacBookPro7,1 and FreeBSD 8.1
* Hans Petter Selasky , 20101112 21:33: > This might be because your model is not listed in a quirk-table: > > grep -ri macbook /usr/src/sys/amd64 > > /usr/src/sys/amd64/amd64/machdep.c If only we could live without that hack... I remember we once did this for all MacBooks, no specific revision whatsoever. -- Ed Schouten WWW: http://80386.nl/ pgpwq8YTjdL9n.pgp Description: PGP signature
Re: libcompiler_rt now part of FreeBSD's base system
Florian, others, * Florian Smeets , 20101112 15:57: > i'm at r215149 on sparc64, and my compiler stopped working. buildworld > stops after 42 lines (http://smeets.im/~flo/bw.log). cc1 dumps a 1GB > core file. I'll look into as soon as possible, but to prevent additional breakage, I've switched sparc64 back to the original libgcc. -- Ed Schouten WWW: http://80386.nl/ pgp1COBdVlSe2.pgp Description: PGP signature
libcompiler_rt now part of FreeBSD's base system
Hello all, I just committed libcompiler_rt.a to HEAD. Even though I don't expect serious issues -- especially not on the tier 1 architectures -- be sure to contact me in case something goes wrong. I hooked it up to the build in a separate commit, so if your system starts to act weird, just revert r215127. Thanks to everyone who helped testing this! -- Ed Schouten WWW: http://80386.nl/ - Forwarded message from Ed Schouten - > Date: Thu, 11 Nov 2010 15:48:27 + (UTC) > From: Ed Schouten > To: src-committ...@freebsd.org, svn-src-...@freebsd.org, > svn-src-h...@freebsd.org > Subject: svn commit: r215127 - in head: . gnu/lib/libgcc lib sys/sys > > Author: ed > Date: Thu Nov 11 15:48:27 2010 > New Revision: 215127 > URL: http://svn.freebsd.org/changeset/base/215127 > > Log: > Replace libgcc.a by libcompiler_rt.a. > > libcompiler_rt.a is a BSD licensed C language runtime, which implements > many routines which are linked into binaries on architectures where > certain functionality is missing (e.g. 64 bits mul/div on i386). > > Unfortunately, libcompiler_rt cannot replace libgcc entirely. Certain > features, such as an unwinder for exception handling, are missing. > That's why only libgcc.a is replaced for now, because this one does seem > to be complete. > > Tested by: rene (amd64), nwhitehorn (powerpc), droso (i386 exprun) > and many others. Thanks! > Obtained from: user/ed/compiler-rt > > - End forwarded message - pgpFfnvWsty91.pgp Description: PGP signature
Re: Syscons and termcap
* Gary Jennejohn , 20101109 18:58: > This may seem like a stupid comment, but I'd say that the "iso" does > not imply UTF-8 support. In fact, there seem to be only ISO or code > page keymaps under /usr/share/syscons/keymaps. But I'm no keymap > expert. Well, the funny thing about Unicode is that the first 256 codepoints are equal to ISO-8859-1, so if you recode ISO-8859-1 to the multibyte representation of UTF-8, it all works. This is why you could use such a keymap without issues. -- Ed Schouten WWW: http://80386.nl/ pgprWDwdQwCiP.pgp Description: PGP signature
Re: Syscons and termcap
* Renato Botelho , 20101109 17:08:
> Well, few weeks ago I moved from ISO-8859-1 to UTF-8 on my Xorg
> environment, and after reading this I decided to make a test.
>
> I rebuilt my 9.0-current (r215031) with option TEKEN_UTF8 in kernel
> config, and after configure my syscons to use cp850-* fonts i can
> see UTF-8 chars properly \o/
Well, the point here is that it just performs some really hackish
translation to CP437, not CP850, on the output path. It is really not
robust. Copy-pasting is also broken because of it, because it pastes
CP437 characters.
> The only thing i cannot do here is to type chars with accent like áé
> on console, because it seems to don't respect deadkeys, when I
> press ' the char ' is show and never wait the next char to compose
> a new one when necessary. Is it a knwon issue or i'm doing
> something wrong?
This is a known issue, since there is no translation from Unicode code
points to UTF-8 sequences. In other words, if you press ë, the keyboard
layer will properly send a 235 to Syscons, but instead of encoding it as
0xC3 0xA9, will just emit a single byte, having value 0xE9.
Maybe a patch like this could already get that working, but it's just a
quick hack.
http://80386.nl/pub/syscons-utf8.txt
Greetings,
--
Ed Schouten
WWW: http://80386.nl/
pgpDFXZrgCmH7.pgp
Description: PGP signature
Re: Syscons and termcap
Hello Eir, * Eir Nym , 20101109 05:10: > I've compiled -CURRENT kernel with UTF-8 and CONS25 support. ( r214751 ) > > in xterm emulation mode I have problems with bindings for some keys, > such as Home > If I start vis(1) and press Home, I always get "^[[H" sequence instead > of "^[OH" which is defined in termcap (5) file. > > I get correct results after switching to cons25. > > What do I wrong ? Does sc(4) driver in current correctly support > xterm-like key bindings? Yes, but not only must you set TERM=xterm, you must also remove TEKEN_CONS25 from your kernel configuration or run vidcontrol -T xterm on that specific window. There is almost no reason why anyone would want to use the TEKEN_CONS25 option. Depending on whether the terminal is switched to cursor keys mode, it will return ^[[H or ^[OH. See /sys/teken/teken.c, teken_get_sequence(). Greetings, -- Ed Schouten WWW: http://80386.nl/ pgpphkXc4hfeS.pgp Description: PGP signature
Re: libstc++ (?) problem on CURRENT?
* Barbara , 20101106 10:57: > Just to be clear, I'm not looking for a solution about the port here, > I'm just wondering why the same c++ code is working on 8_STABLE and > it's segfaulting on CURRENT, considering also that AFAIK the gcc > version in both the base systems is the same. I am a real STL newbie, so I could be wrong. Maybe it's not allowed to remove an element in the map you're currently iterating. Therefore you're accessing memory which has been deallocated. This may crash on HEAD and not on 8-STABLE for various reasons. For example, malloc() in HEAD has all sorts of debugging options enabled, while 8-STABLE does not. Greetings, -- Ed Schouten WWW: http://80386.nl/ pgpVzkBGkeJh8.pgp Description: PGP signature
Re: utmpx
* Renato Botelho , 20101105 13:49: > I've made a patch for chkrootkit [1], it's building, but i didn't test if > it's working. Could you take a look at it? > > [1] http://people.freebsd.org/~garga/patches/chkrootkit-utmpx.diff Well, files cannot be accessed without the utmpx API. I looked at these tools and I don't think they have very little use with utmpx. Can't we just disable all utmp related tools? -- Ed Schouten WWW: http://80386.nl/ pgpdkBkdF8yTY.pgp Description: PGP signature
Re: utmpx
* Anonymous , 20101105 12:58: > There are more, see ports listed under utmpx.h in > > http://wiki.freebsd.org/PortsBrokenOnCurrent It should be noted that that list is a bit pessimistic, since various ports have been fixed in the mean time. Greetings, -- Ed Schouten WWW: http://80386.nl/ pgpXvvDd3DgZl.pgp Description: PGP signature
Re: Openoffice doesn't work with kernel+world built with Clang
* Renato Botelho , 20101103 15:36:
> On Wed, Nov 3, 2010 at 11:44 AM, Ed Schouten wrote:
> > Garga!
> >
> > * Renato Botelho , 20101103 13:36:
> >> For now i solve my problem adding this to /etc/src.conf
> >>
> >> .if ${.CURDIR} == "/usr/src/gnu/lib/libgcc"
> >> CC=cc
> >> CXX=c++
> >> .endif
> >>
> >> This way libgcc_s.so is built using gcc instead of clang and the problem
> >> is gone. I just wonder other problems we can find since simething on
> >> libgcc_s.so is broken when built with clang.
> >
> > Would it be hard to figure out which exact object file causes this?
>
> Hi Ed,
>
> I've submitted a ktrace result of openoffice execution [1], i just
> saw it got a SIGBUS at some point, but debug openoffice doesn't
> seem to be a trivial task.
>
> I don't know if we can build OO with debug symbols to make it
> easier to debug. If you know what i can do to help debugging,
> just let me know and i can provide any information.
Well, I mean, can you build some of libgcc's object files with Clang and
others with GCC? Hint: Just build everything with GCC. Afterwards, go
into the object directory, rm some of the .o files and make CC=clang.
Since OOo is a C++ application, I suspect the unwind-related object
files to be the culprit.
--
Ed Schouten
WWW: http://80386.nl/
pgp6Mq6wCrRKK.pgp
Description: PGP signature
Re: 9-CURRENT: ports/net/kdenetwork3 does not compile
Hello all,
Just to notify everyone what's going on; Matthias tested a patch for me,
which should make it work on HEAD again. The attached patch should be
applied to the sources conditionally (so only when running HEAD). I am
in the process of getting it fixed in ports/upstreamed.
Greetings,
--
Ed Schouten
WWW: http://80386.nl/
--- ktalkd/ktalkd/find_user.cpp
+++ ktalkd/ktalkd/find_user.cpp
@@ -339,34 +339,33 @@
#else /*not PROC_FIND_USER*/
+#include
+
int find_user(char *name, char *tty, char *disp) {
-struct utmp ubuf;
+struct utmpx *ubuf;
int status;
-FILE *fd;
struct stat statb;
-char ftty[20+UT_LINESIZE];
-char ttyFound[UT_LINESIZE] = "";
-char dispFound[UT_HOSTSIZE+1] = "";
-
-if (!(fd = fopen(_PATH_UTMP, "r"))) {
-fprintf(stderr, "talkd: can't read %s.\n", _PATH_UTMP);
-return (FAILED);
-}
+char ftty[20 + sizeof ubuf->ut_line];
+char ttyFound[sizeof ubuf->ut_line] = "";
+char dispFound[sizeof ubuf->ut_line + 1] = "";
+
+setutxent();
#define SCMPN(a, b)strncmp(a, b, sizeof (a))
status = NOT_HERE;
(void) strcpy(ftty, _PATH_DEV);
-while (fread((char *) &ubuf, sizeof ubuf, 1, fd) == 1) {
-if (!SCMPN(ubuf.ut_name, name)) {
+while ((ubuf = getutxent())) {
+if ((ubuf->ut_type == USER_PROCESS) &&
+(!SCMPN(ubuf->ut_user, name))) {
if (*tty == '\0') {
/* no particular tty was requested */
-(void) strcpy(ftty+5, ubuf.ut_line);
+(void) strcpy(ftty+5, ubuf->ut_line);
if (stat(ftty,&statb) == 0) {
if (!(statb.st_mode & 020)) /* ?character device? */
continue;
-(void) strcpy(ttyFound, ubuf.ut_line);
+(void) strcpy(ttyFound, ubuf->ut_line);
#ifdef USE_UT_HOST
-(void) strcpy(dispFound, ubuf.ut_host);
+(void) strcpy(dispFound, ubuf->ut_host);
strcat(dispFound, " ");
#endif
status = SUCCESS;
@@ -384,13 +383,13 @@
}
}
}
- else if (!strcmp(ubuf.ut_line, tty)) {
+ else if (!strcmp(ubuf->ut_line, tty)) {
status = SUCCESS;
break;
}
}
}
-fclose(fd);
+endutxent();
if (status == SUCCESS) {
(void) strcpy(tty, ttyFound);
(void) strcpy(disp, dispFound);
pgpHdoKZt6XfX.pgp
Description: PGP signature
[Announcement] New mailing list: toolch...@freebsd.org
Hello everybody, The last couple of months we've been seeing quite a lot of traffic on several of the FreeBSD mailing lists (especially on current@) related to compilers, linkers, debuggers, etc. This is why Brooks Davis and I decided it would be a good thing to create a new mailing list. Behold, : http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain Be sure to subscribe to this list if you're interested in tracking what's going on with our toolchain. Though I guess it will be primarily used to discuss things like Clang, it should also be a suitable place to discuss other components of the toolchain (linker, assembler, runtime libraries). Greetings, -- Ed Schouten WWW: http://80386.nl/ pgpLjvHsdDeF1.pgp Description: PGP signature
Re: Tested wanted: BSD-licensed libgcc replacement, libcompiler_rt
Hi all, * Ed Schouten , 20101022 16:30: > At EuroBSDCon I was talking with some committers active in the area of > Clang (brooks, kwm, others) about replacing our libgcc shipped with GCC > 4.2.1 with a BSD-licensed version. The LLVM folks have a BSD licensed > implementation called libcompiler_rt. See: > > http://compiler-rt.llvm.org/ I was talking with Robert Watson about this the other day. The codebase of compiler-rt also contains the libBlocksRuntime.so library, which is fundamental in making Grand Central Dispatch (GCD) work. Because of its small size (12 KB), I think I'll also include it in the import. This means that after the import, libdispatch is the only port needed to make Grand Central Dispatch work on FreeBSD HEAD. -- Ed Schouten WWW: http://80386.nl/ pgpyBb6J3YDS1.pgp Description: PGP signature
Re: Tested wanted: BSD-licensed libgcc replacement, libcompiler_rt
* Ed Schouten , 20101022 16:30: > - Rebuild all your software (yes, I know it's unfortunate). Right after I sent this, I thought I'd better clarify this. You don't need to rebuild your software. This change will not break the existing ABI. This step is just mentioned here, since libgcc.a is statically linked into applications. Simply rebuilding and reinstall world is not sufficient to make 3rd party applications use this. -- Ed Schouten WWW: http://80386.nl/ pgph9jTT1tKjk.pgp Description: PGP signature
Tested wanted: BSD-licensed libgcc replacement, libcompiler_rt
Hello everyone, At EuroBSDCon I was talking with some committers active in the area of Clang (brooks, kwm, others) about replacing our libgcc shipped with GCC 4.2.1 with a BSD-licensed version. The LLVM folks have a BSD licensed implementation called libcompiler_rt. See: http://compiler-rt.llvm.org/ Right now it is already complete enough to replace libgcc.a and libgcc_p.a (mostly math rountines), but it doesn't yet implement the functionality (e.g. unwinder) to replace libgcc_eh.a, libgcc_eh_p.a and libgcc_s.so.1. I've created a branch in Subversion which replaces libgcc.a and libgcc_p.a with libcompiler_rt.a and libcompiler_rt_p.a and symlinks it to the original names. It seems to survive a `make universe' and it works properly on at least amd64. Right now the only issue I can think of, is that __clear_cache() is broken on ARM, but that can be fixed trivially. My plan would be to commit this work to HEAD by the end of November (1 month from now), but it would be nice if it could get some more testing in the mean time, especially on non-x86 architectures. How to test this: - Check out the branch from SVN: svn co svn://svn.freebsd.org/base/user/ed/compiler-rt/ - Rebuild and reinstall world (and kernel). - Rebuild all your software (yes, I know it's unfortunate). - See whether software crashes or misbehaves, while it didn't do that previously. In the mean time, I'll see if I can get the Ports folks to run an exp-run with this branch, which should already give some coverage. Thanks! -- Ed Schouten WWW: http://80386.nl/ pgp4nEKTk6e5K.pgp Description: PGP signature
truss calls setpgid()
Hi all,
I've been seeing this bug for a very long time, but I was too lazy to
figure out the root cause earlier. It is TTY related, but in this case
the TTY layer is not to blame. It does things correctly.
When you run a command in truss which calls ioctls on TTYs, it just
locks up. This is because truss runs jobs in a separate process group.
This also means you cannot send signals to it:
truss sleep 1
Pressing ^C here won't work.
I've fixed it locally like this:
Index: usr.bin/truss/setup.c
===
--- usr.bin/truss/setup.c (revision 213113)
+++ usr.bin/truss/setup.c (working copy)
@@ -78,7 +78,6 @@
}
if (pid == 0) { /* Child */
ptrace(PT_TRACE_ME, 0, 0, 0);
- setpgid (0, 0);
execvp(command[0], command);
err(1, "execvp %s", command[0]);
Question: was this intentional? I'd rather not break stuff.
Greetings,
--
Ed Schouten
WWW: http://80386.nl/
pgpgLNWsANUMZ.pgp
Description: PGP signature
Re: Examining the VM splay tree effectiveness
Andre, * Andre Oppermann wrote: > A splay tree is an interesting binary search tree with insertion, > lookup and removal performed in O(log n) *amortized* time. With > the *amortized* time being the crucial difference to other binary trees. > On every access *including* lookup it rotates the tree to make the > just found element the new root node. For all gory details see: > http://en.wikipedia.org/wiki/Splay_tree Even though a red-black tree is quite good since it guarantees a $2 \log n$ upperbound, the problem is that it's quite computationally intensive. Maybe it would be worth looking at other types of balanced trees? For example, another type of tree which has only $O(\log n)$ amortized insertion/removal/lookup time, but could already be a lot better in practice, is a Treap. Greetings, -- Ed Schouten WWW: http://80386.nl/ pgppFv0Ft9fqs.pgp Description: PGP signature
