Re: [RFC] last(1) with security.bsd.see_other_uids support
2012/6/6 Pawel Jakub Dawidek : > Any privileged daemon is much bigger threat. Also, do we really want a > daemon running all the time just to be able to parse utx files? Well, if you think of it, it's not a very strange idea: - You can simply get rid of /var/run/utx.active. There's no need for this to be written to disk. It can just stay in memory. - You can use devd to track the destruction of TTYs, so you can automatically garbage collect stale entries for pseudo-terminals. Right now a `killall -9 xterm' may leave stale entries behind. - The other files aren't _that_ big. On FreeBSD, utx.log only stores entries for the last month. Especially if you implement getutxid()/getutxuser() as separate calls, much of the filtering is already done by the daemon. -- Ed Schouten ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [RFC] last(1) with security.bsd.see_other_uids support
2012/6/5 Jilles Tjoelker : > To avoid this, the utmpx APIs could communicate with a privileged daemon > if the files are not readable. The daemon can check the identity of the > caller via getpeereid(3). +1. I would really like to have something like this. Another advantage of this approach would be that it's a lot easier to change the file format then. There's only one application that interacts with these files. -- Ed Schouten ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [RFC] last(1) with security.bsd.see_other_uids support
Hi Bryan, 2012/6/4 Bryan Drewery : > * Added utmp group Why call it utmp? FreeBSD 9+ does not do utmp. It does utmpx. Also, too many pieces of software already abuse the group `utmp'. Instead of doing utmp handling with it, it is used to cover all sorts of "this uses TTYs" scenarios. It wouldn't amaze me if even irssi has setuid utmp on some systems, simply because it runs on a TTY. Also, there's no need for consistency. This group name would only be used by the C library to apply ownership, the log rotator and some of our tools. Still, I wonder whether it's worth the effort. In its current form, you can simply chmod 0600 the utx.* files to hide the information inside to non-administrative users. I guess you can essentially decide to make any tool setuid, simply because it can print things referring to a user. For example, why not have a tool that allows regular users to view their own auth.log entries? > @@ -212,7 +255,30 @@ struct idtab { > /* Load the last entries from the file. */ > if (setutxdb(UTXDB_LOG, file) != 0) > err(1, "%s", file); > + > + /* drop setgid now that the db is open */ > + setgid(getgid()); > + > + /* Lookup current user information */ > + pw = getpwuid(getuid()); > + > + len = sizeof(see_other_uids); > + if (sysctlbyname("security.bsd.see_other_uids", &see_other_uids, &len, > NULL, 0)) > + see_other_uids = 0; > + restricted = is_user_restricted(pw, see_other_uids); > + > while ((ut = getutxent()) != NULL) { > + /* Skip this entry if the invoking user is not permitted > + * to see it */ > + if (restricted && > + !(ut->ut_type == BOOT_TIME || > + ut->ut_type == SHUTDOWN_TIME || > + ut->ut_type == OLD_TIME || > + ut->ut_type == NEW_TIME || > + ut->ut_type == INIT_PROCESS) && > + strncmp(ut->ut_user, pw->pw_name, > sizeof(ut->ut_user))) > + continue; > + > if (amount % 128 == 0) { > buf = realloc(buf, (amount + 128) * sizeof *ut); > if (buf == NULL) > Though not a common case, this code will not work properly when multiple users share the same uid. Consider comparing against the username of the logged in user (see getlogin(2)), or resolving the uid for each entry and comparing the uids. Best regards, -- Ed Schouten ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Small tool: fixwhite(1)
Hi folks, I just added a small tool to the tools/ directory in src called fixwhite(1) that attempts to fix commonly made whitespace bugs in source files. I wrote it in such a way that it's quite conservative, to make sure it won't make too many annoying changes that you have to roll back manually. It should be useful especially when copy-pasting code between terminals. As mentioned in the commit message, you can just use :%!fixwhite if you're a vi(1) user. Other editors probably support a similar construct. Have fun! -- Ed Schouten WWW: http://80386.nl/ - Forwarded message from Ed Schouten - > Date: Mon, 6 Feb 2012 10:23:11 +0000 (UTC) > From: Ed Schouten > To: src-committ...@freebsd.org, svn-src-...@freebsd.org, > svn-src-h...@freebsd.org > Subject: svn commit: r231071 - head/tools/tools/fixwhite > > Author: ed > Date: Mon Feb 6 10:23:11 2012 > New Revision: 231071 > URL: http://svn.freebsd.org/changeset/base/231071 > > Log: > Add fixwhite(1). > > This small utility can be used to `sanitize' the whitespace in source > code. It does the following things: > > Global: > - Remove empty lines at the beginning and the end of a file. > - Merge successive empty lines into a single empty line. > > Per-line: > - Remove trailing whitespace. > - Merge spaces preceeding tabs into the tabs. > > It operated on stdin/stdout. This means that if you use vi(1), you can > just run :%!fixwhite to reorganize the file. - End forwarded message - pgpL2cPVW0sdr.pgp Description: PGP signature
Re: dup3 syscall - atomic set O_CLOEXEC with dup2
Hi Kostik, * Kostik Belousov , 20120112 11:08: > > +int > > +sys_dup3(struct thread * const td, struct dup3_args * const uap) { > The td and uap are not constant in the prototypes generated by > makesyscalls.sh. This makes me seriosly wonder was the patch compiled at > all. This is because the parameters itself are const -- not the objects they point to. e.g: int foo(int); int foo(const int i) { /* code here */ } -- Ed Schouten WWW: http://80386.nl/ pgpKSAVj4LrZi.pgp Description: PGP signature
Re: dup3 syscall - atomic set O_CLOEXEC with dup2
* Ed Schouten , 20120112 10:56: > I suspect that not long after we add dup3(), some random person asks us > to implement F_DUP3FD. Any chance you can implement this without using a > system call, but through fcntl()? Never mind. This seems to be non-trivial, as fcntl() just takes a single parameter and dup3() requires the newfd and the flags. -- Ed Schouten WWW: http://80386.nl/ pgpABvOKMHAi3.pgp Description: PGP signature
Re: dup3 syscall - atomic set O_CLOEXEC with dup2
Hello Eitan, * Eitan Adler , 20120112 06:01: > This is an implementation of dup3 for FreeBSD: > man page here (with a FreeBSD patch coming soon): > https://www.kernel.org/doc/man-pages/online/pages/man2/dup.2.html > > Is this implementation correct? If so any objection to adding this as > a supported syscall? I suspect that not long after we add dup3(), some random person asks us to implement F_DUP3FD. Any chance you can implement this without using a system call, but through fcntl()? Thanks, -- Ed Schouten WWW: http://80386.nl/ pgpk2dytKI6SM.pgp Description: PGP signature
Re: Communication between kernel and userspace via local socket
* Maxim Ignatenko , 2015 21:18: > I'm currently inventing the wheel^W^W^Wwriting a firewall from scratch and > looking for most convenient way to establish communication between userspace > processes and kernel part. Communication pattern best fits to listening > PF_LOCAL socket opened from kernel and userspace processes connecting to it. What's wrong with a character device? -- Ed Schouten WWW: http://80386.nl/ pgpdZgbXYqVSE.pgp Description: PGP signature
Re: BUG: 'glabel label' name's lenght, is truncated without err/warn
Hi Andrew, * Andrew Duane , 2008 16:22: > Checking the return code of strlcpy won't say if the entire string fit > (exactly) correctly, or if it was truncated. It seems they do: RETURN VALUES The strlcpy() and strlcat() functions return the total length of the string they tried to create. For strlcpy() that means the length of src. For strlcat() that means the initial length of dst plus the length of src. While this may seem somewhat confusing, it was done to make trunca‐ tion detection simple. -- Ed Schouten WWW: http://80386.nl/ pgp3k0xKTMyC1.pgp Description: PGP signature
Re: BUG: 'glabel label' name's lenght, is truncated without err/warn
* Lucas Holt , 2005 15:24: > --- src/sbin/geom/class/label/geom_label.c2008/11/21 21:05:31 1.3 > +++ src/sbin/geom/class/label/geom_label.c2011/11/05 14:15:23 1.4 > @@ -118,6 +118,12 @@ label_label(struct gctl_req *req) > return; > } > > + label = gctl_get_ascii(req, "arg0"); > + if (strlen(label) > 15) { > + gctl_error(req, "Label cannot exceed 15 characters"); > + return; > + } > + > /* >* Clear last sector first to spoil all components if device exists. >*/ > @@ -131,7 +137,6 @@ label_label(struct gctl_req *req) > > strlcpy(md.md_magic, G_LABEL_MAGIC, sizeof(md.md_magic)); > md.md_version = G_LABEL_VERSION; > - label = gctl_get_ascii(req, "arg0"); > strlcpy(md.md_label, label, sizeof(md.md_label)); > md.md_provsize = g_get_mediasize(name); > if (md.md_provsize == 0) { Why not simply perform the strlcpy and check whether if (strlcpy(...) >= sizeof(md.md_label) ? -- Ed Schouten WWW: http://80386.nl/ pgpiTKtTnUUyN.pgp Description: PGP signature
Re: [PATCH] avoid assuming MAXPATHLEN in config(8)
* Robert Millan , 20110707 13:12: > As for the __GLIBC__ bit, it is difficult to handle this without a > function that canonicalizes arbitrary-length pathnames. Would you > prefer something like: > > #ifdef MAXPATHLEN > // use realpath on a statically-allocated buffer > #else > // assume canonicalize_file_name() is present > #endif Considering that the function is rather small anyway, why not compile it in unconditionally (though having a different name). -- Ed Schouten WWW: http://80386.nl/ pgpCxVFvPVCKF.pgp Description: PGP signature
Re: [PATCH] avoid assuming MAXPATHLEN in config(8)
Hi Robert, * Robert Millan , 20110707 11:33: > config(8) assumes MAXPATHLEN is defined in a few places, but presence > of this macro isn't garanteed (POSIX says that it is only present when > a file length limit exists, which may not be the case). Even though it is good to make our code conform to standards as much as possible, do keep in mind that your patch also causes a lot of regressions in that area. The code now uses asprintf(), which is not part of POSIX. I also think the use of __GLIBC__ is frowned upon. -- Ed Schouten WWW: http://80386.nl/ pgpSZpTBufHTD.pgp Description: PGP signature
Re: [PATCH] build config(8) on GNU systems
Fixed in r223744. Thanks! -- Ed Schouten WWW: http://80386.nl/ pgpBp8MHciKH9.pgp Description: PGP signature
Re: [PATCH] build config(8) on GNU systems
* Zhihao Yuan , 20110703 22:22: > Programmers always want to make things "cooler". Just leave the > ->d_namlen there :) Portability isn't achieved by adding #ifdefs, but by writing portable code. ;-) -- Ed Schouten WWW: http://80386.nl/ pgpbqUUDWhNbF.pgp Description: PGP signature
Re: [PATCH] build config(8) on GNU systems
* Robert Millan , 20110702 16:56: > Index: usr.sbin/config/main.c > === > --- usr.sbin/config/main.c(revision 223721) > +++ usr.sbin/config/main.c(working copy) > @@ -591,7 +591,11 @@ > if ((dirp = opendir(p)) == NULL) > err(EX_OSERR, "opendir %s", p); > while ((dp = readdir(dirp)) != NULL) { > +#ifdef _DIRENT_HAVE_D_NAMLEN > i = dp->d_namlen - 2; > +#else > + i = strlen (dp->d_name) - 2; > +#endif > /* Skip non-headers */ > if (dp->d_name[i] != '.' || dp->d_name[i + 1] != 'h') > continue; Why not simply use strlen() unconditionally? -- Ed Schouten WWW: http://80386.nl/ pgpjq8GSwsoLs.pgp Description: PGP signature
Re: State of FreeBSD/xbox
Hi Chris, Kostik, * Kostik Belousov , 20110403 21:26: > On Sun, Apr 03, 2011 at 07:40:14PM +0100, Chris Rees wrote: > > In short-- FreeBSD/xbox is bitrotted (or so it appears!) Well, I did run FreeBSD HEAD on my Xbox only a couple of weeks ago and it worked properly. I remember jhb@ made some PCI changes some time ago that caused some breakage, but that got fixed as far as I know. So what kind of problems are you experiencing? > I wanted to remove XBOX for long time. With the introduction of Xen PV, > i386/machdep.c became too convoluted. On the other hand, if you can > bring it back to life, I definitely would not have an argument for removal. Sure. It was pretty awesome to see FreeBSD run on an Xbox, but nowadays you can even get Android phones having better specs. Say, if the Xbox code makes it hard to implement some kind of cool feature, I really wouldn't mind seeing it go, as long as it's left the way it is in the stable branches. -- Ed Schouten WWW: http://80386.nl/ pgpg2NnM0Etlr.pgp Description: PGP signature
Re: Simple kernel attack using socketpair.
On Nov 26, 2010, at 11:26, Ivan Klymenko wrote: > Rumor has it that this vulnerability applies to FreeBSD too, with the > replacement SOCK_SEQPACKET on SOCK_DGRAM... > > http://lkml.org/lkml/2010/11/25/8 > > What do you think about this? I'm not sure, but it seems to be related to some kind of stack overflow in close(), where each close() on a socket generates an additional close() call of the inflight sockets. -- Ed Schouten WWW: http://80386.nl/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: 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/ pgpssyE3e4sFK.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/ pgpbcBir7S44Y.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/ pgpxtVH6ehp5C.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/ pgpcTegdy4WZ3.pgp Description: PGP signature
Re: A simple and hopefully usable FreeBSD live CD -- now with images
Hello Mubeesh, * Mubeesh ali wrote: > Please excuse for my question: Is this a compressed version or all we need > to do is to rename it to *.iso ? > after renaming it did not boot in vmware . Yes, it's compressed with xz(1). Just run unxz to decompress it. It should be part of the latest FreeBSD releases. If not, be sure to install /usr/ports/archivers/xz. Greetings, -- Ed Schouten WWW: http://80386.nl/ pgp7FCLPTM5t8.pgp Description: PGP signature
A simple and hopefully usable FreeBSD live CD -- now with images
Hi all, Per Lars's request I've uploaded an ISO of the FreeBSD live CD for amd64: URL:http://people.freebsd.org/~ed/FreeBSD-9.0-CURRENT-201008-amd64-ed.iso.xz Size: 422452056 bytes (403 MB) SHA256: e0b7ac8eac713ecd5ccdbf107c80563260e6000b27838b003ca11a42ae6ae700 Have fun! -- Ed Schouten WWW: http://80386.nl/ pgpApzTt0kvES.pgp Description: PGP signature
Re: A simple and hopefully usable FreeBSD live CD
* Lars Engels wrote: > could you please upload the resulting ISO so that people who don't > want to create it themselves can test your CD? Prrr... I have a horrible internet connection and the resulting ISO is about 600 MB big. I'll see what I can do. -- Ed Schouten WWW: http://80386.nl/ pgpff35ZrLT3j.pgp Description: PGP signature
Re: A simple and hopefully usable FreeBSD live CD
* Tim Judd wrote: > Your CDs won't reach as many people as possible, I fear. I fear because I > (for example) have no amd64 systems and just by the name of the snapshot cd > image i need to have to use your script, I won't be able to use the final > product. Well, the script makes some assumptions it shouldn't. You can simply build i386 CDs by substituting all occurences of amd64 by i386 in gencd.sh. Porting it to non-x86 architectures isn't hard either, but I haven't looked at it at all. It should be fairly straightforward to accomplish that when integrating it into the release(7) infrastructure. The current shellscript is just a mockup. -- Ed Schouten WWW: http://80386.nl/ pgpqpSStEb5hy.pgp Description: PGP signature
A simple and hopefully usable FreeBSD live CD
Hello all, A couple of major releases ago, we had a FreeBSD disc1.iso which also included the livefs. Nowadays the livefs comes on a separate disc. This livefs disc has a couple of issues in my opinion: - The livefs disc does not feature any installsets, which means if your system has 1 CD-ROM drive, you have to resort to network connectivity to obtain the installsets to perform a manual install. - The livefs installation places everything in /dist and does some odd tricks to get the basic things working, which means that any tool that assumes a specific pathname doesn't work anymore. I remember the GEOM tools were once broken because of this. You also have to add symlinks here and there to make something as simple as scp(1) work, because the ssh(1) binary is in the wrong place. I think I already mentioned it on some of the lists, but I've spent some time creating a better FreeBSD live CD (or at least I tried to). Basically the CD is just a stock FreeBSD installation (base + manpages + kernel) with a small mfsroot between the boot process to let it use unionfs and tmpfs before calling into /sbin/init. You can just run adduser, dhclient and fire up a SSH daemon. It's exactly the same as an installation of FreeBSD on a harddisk, with the only exception that any changes don't survive a reboot. It also has a copy of all the installsets, which means you can do installations and recoveries. I've attached a copy of the script I use to generate the CD. Just make sure you have FreeBSD-9.0-CURRENT-201008-amd64-disc1.iso placed in the same directory as the script and that you have an up-to-date HEAD source tree in /usr/src, with a GENERIC kernel already built. You also need to have cdrtools installed. After that, you should be able to run gencd.sh as root (needed for retaining file permissions), which should generate a FreeBSD-9.0-CURRENT-201008-amd64-ed.iso. Right now it still requires the source tree, because the fixes for tmpfs needed to make it all work aren't in the 201008 snapshot. By the time 201009 is released, the script can easily be modified to use the kernel binaries. I'm sending this email for two different reasons: 1. Be sure to give the CD a try and share your experiences. Does it work? Does it crash? Is it usable for you? If not, why not? 2. Would a CD like this be a good addition to the provided install media? Does it actually solve shortcomings of the existing media? If people think it's a nice CD to work with, I could consider integrating it into release(7). Thanks! -- Ed Schouten WWW: http://80386.nl/ freebsd-bootcd.tar.gz Description: Binary data pgpEq9MbOmBDP.pgp Description: PGP signature
Re: Data truncation on ptys
Hello Michael, * Michael Sperber wrote: > I'm one of the maintainers of XEmacs, and I've been running into a > persistent problem with subprocesses / ptys since at least 5.x. (If this > is not the right list, I'd appreciate a pointer to a more appropriate > forum.) Very quick question. Does this problem still occur on FreeBSD 8.x? FreeBSD 8.x has an entirely new TTY layer, which includes a new pseudo-terminal driver. Greetings, -- Ed Schouten WWW: http://80386.nl/ pgpR8RWIRgJks.pgp Description: PGP signature
Re: Problem detecting and reacting to serial break
* Paul Thornton wrote: > I'm using 8.0-RELEASE with uftdi and ucom driving the serial port. Somewhat unrelated question: have you ever tried running the this code on 7.x? If so, did it work? -- Ed Schouten WWW: http://80386.nl/ pgp1PRCv6Lq6n.pgp Description: PGP signature
Re: sysctl way too slow
* Atom Smasher wrote: > http://smasher.org/tmp/zsh-bsd-sysctl-slow.png > > is there a way to get this information that doesn't take so long? > > the same info is available on linux via /sys and /proc and on > comparable hardware, i can get the info about 100x faster. So what about other sysctls? Is it just these sysctls? It may be the case that these values are not simply read from some variable in the kernel, but really performs some hardware calls. Still, 436 msec is quite a lot of time. -- Ed Schouten WWW: http://80386.nl/ pgpcbRRsFxAZF.pgp Description: PGP signature
Re: inet_* functions in kernel?
Hi Bartosz, * Bartosz Marcin Kojak wrote: > I want to be able to write rules for module through sysctl (rule > will contain IP addresses in human-readable format, e.g. > "uid:1002:192.168.2.3") and I'm wondering how to translate addresses > to network byte order without inet_* functions. Wouldn't it be possible to do the conversion in userspace and write something like a struct sockaddr_storage/in_addr_t/etc to the kernel? That way you can avoid the string handling in kernel space entirely. -- Ed Schouten WWW: http://80386.nl/ pgpADusBRjZe7.pgp Description: PGP signature
Re: sysctl question
* Andreas Tobler wrote: > But now I wonder how can I teach the sysctl to print my tempreature > the same way as my userland app does. I seem to remember all the other temperature sensors expose their value using tenth Kelvin precision. There is some kind of modifier you can add to the SYSCTL_INT declaration to denote that it's a temperature value. The sysctl(8) code on HEAD seems to suggest the type is "IK". Greetings, -- Ed Schouten WWW: http://80386.nl/ pgpN5VezoVfCk.pgp Description: PGP signature
Re: an alternative to powerpoint
* Bakul Shah wrote: > I went looking for a latex class and found 'Prosper'. Why not use the `beamer' class? http://bitbucket.org/rivanvx/beamer/wiki/Home This is what I always use to prepare my slides. Works great. -- Ed Schouten WWW: http://80386.nl/ pgpcJX5O25Jc4.pgp Description: PGP signature
Re: using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)]
* Mike Meyer wrote: > Maybe it's time for /usr/sbin/lpwrapper, to do the same thing for > print systems? In my opinion, we should just rename mailwrapper to whateverwrapper and list the lpr programs in there as well. -- Ed Schouten WWW: http://80386.nl/ pgpn1LzLEWm9v.pgp Description: PGP signature
Re: using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)]
* Andrew Reilly wrote: > On Thu, Jun 24, 2010 at 09:23:37AM +0200, Gary Jennejohn wrote: > > in /etc/src.conf - WITHOUT_LPR=yes > > > > and these symbolic links in /usr/bin > > lrwxr-xr-x 1 root wheel 17 Mar 18 2009 /usr/bin/lp -> > > /usr/local/bin/lp > > lrwxr-xr-x 1 root wheel 24 Mar 18 2009 /usr/bin/lpoptions -> > > /usr/local/bin/lpoptions > > lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpq -> > > /usr/local/bin/lpq > > lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpr -> > > /usr/local/bin/lpr > > lrwxr-xr-x 1 root wheel 19 Mar 18 2009 /usr/bin/lprm -> > > /usr/local/bin/lprm > > lrwxr-xr-x 1 root wheel 21 Mar 18 2009 /usr/bin/lpstat -> > > /usr/local/bin/lpstat > > > > and /usr/bin is _before_ /usr/local/bin in my PATH. > > Since you have /usr/local/bin in your path, why bother with > the symlinks at all? Your shell will find them in their new > locations just fine. You'll want to remove the old ones from > /usr/bin, but make delete-old will probably do that nicely > anyway. In theory, yes. In practice, no. Just for fun, remove your /usr/sbin/sendmail while having Postfix's /usr/local/sbin/sendmail installed. It simply won't work. If I remember correctly, you won't even receive the periodic(8) emails. Nowadays it's probably better, but I remember in the old days GNOME would always print through /usr/bin/lpr, even when CUPS is installed. -- Ed Schouten WWW: http://80386.nl/ pgpNgoKSxOgsT.pgp Description: PGP signature
Re: Moving from FreeBSD7 to FreeBSD8 (cdev, minor, dev2unit)
* Dmitry Krivenok wrote: > - int dev_num = minor(dev); > + int dev_num = minor(dev2unit(dev)); Almost there. Just remove all calls to unit2minor() and minor2unit() (if present) and replace minor() with dev2unit(): int dev_num = dev2unit(dev); But even better, don't use device unit numbers at all. The struct cdev already provides fields like si_drv1 and si_drv2 that can be used to store per-device data. Some drivers use constructs like these: sc = device_get_softc(devclass_get_device(devclass, dev2unit(cdev))); In those cases the code should just be changed to do something similar to the following: cdev = make_dev(); cdev->si_drv1 = sc; Greetings, -- Ed Schouten WWW: http://80386.nl/ pgpfWd3nM8l93.pgp Description: PGP signature
Re: making consmsgbuf_size a tunable?
Hello Matthew, * Matthew Jacob wrote: > Any thoughts about this? Looks good. Maybe we should make it a tunable only? Looking at the code, once the consbuf has been allocated, there is no way you can ever resize it. -- Ed Schouten WWW: http://80386.nl/ pgpvMZK9ULhdP.pgp Description: PGP signature
Re: periodically save current time to time-of-day hardware
* Andriy Gapon wrote: > + timeout(periodic_resettodr, NULL, 1800 * hz); By the way, wouldn't it be a little nicer to use callout(9)? -- Ed Schouten WWW: http://80386.nl/ pgpz0oTdiuq2Z.pgp Description: PGP signature
Re: periodically save current time to time-of-day hardware
* Andriy Gapon wrote: > What do you think about the following patch or something similar? Yes, please. :-) I had an Intel motherboard which had a clock drift. A couple of seconds a day. When I had to reboot after upgrading/etc, it was not a serious problem, but say, the system locked up and rebooted unexpectedly, it always had a huge clock drift if the system had been up for a couple of weeks/months. I recently got rid of that system, but still I think it's a good thing to have. -- Ed Schouten WWW: http://80386.nl/ pgpJmVpQo0Ats.pgp Description: PGP signature
Re: Strange behavior of kernel module (output terminated)
* Dmitry Krivenok wrote: > As you can see the loop was terminated after i==466. > I tried to load/unload the module many times but the last printed number was > always 466. > > Then I compiled the same module on FreeBSD-7.2 (note, the first test was run > on 8.0). > I saw exactly the same behavior except that the last number was always 550. Yes. There is not a single form of flow control here, so if you can't write more data into the TTY buffers, it will just get discarded. FreeBSD 7 does the same thing as 8, but the default buffer sizes are probably a bit different. -- Ed Schouten WWW: http://80386.nl/ pgpGL1yJgnhth.pgp Description: PGP signature
Re: tty or script(1) weirdness?
* Ed Schouten wrote: > Hmmm... It seems this is a TTY bug. When you close a TTY, the final > close() call should get stuck until all data is actually drained. This > doesn't seem to happen properly. Some further research: it's not a TTY bug, but a bug in script(1). The script parent process leaves a file descriptor open, which means output is never properly drained. I can't reproduce this issue after applying this patch: %%% Index: script.c === --- script.c(revision 204965) +++ script.c(working copy) @@ -158,6 +158,8 @@ } if (child == 0) doshell(argv); + else + close(slave); if (flushtime > 0) tvp = &tv; %%% -- Ed Schouten WWW: http://80386.nl/ pgpo052DoqSPZ.pgp Description: PGP signature
Re: tty or script(1) weirdness?
Hi Alfred, * Alfred Perlstein wrote: > 1) download the suite. > 2) run "sh test.sh" to see the bug > 3) run "sh test.sh yes" to not see the bug (sleep called) Hmmm... It seems this is a TTY bug. When you close a TTY, the final close() call should get stuck until all data is actually drained. This doesn't seem to happen properly. You can easily test this by performing a tcdrain() right after running your perl script: #include | int | main(int argc, char *argv[]) | { | | tcdrain(0); | } I'll see what I can do. -- Ed Schouten WWW: http://80386.nl/ pgpDNzomltaDM.pgp Description: PGP signature
Re: [patch] extending {amd64|i386} cpu info
Hello Alexander, * Alexander Best wrote: > + printf(" Stepping = %u" > +" Model = %u" > +" Family = %u", > +cpu_id & CPUID_STEPPING, > +CPUID_TO_MODEL(cpu_id), > +CPUID_TO_FAMILY(cpu_id)); So is there some reason why we don't have a CPUID_TO_STEPPING()? Greetings, -- Ed Schouten WWW: http://80386.nl/ pgpBjDIabfOKa.pgp Description: PGP signature
Re: Deadlock between GEOM and devfs device destroy and process exit.
Hi all, * Kostik Belousov wrote: > My exemplary case has been snp(4) before tty got rewritten, see r. 1.107 > of sys/dev/snp/snp.c. No calls to destroy_dev_sched() that I placed in > the src/ a kept around, that is good because corresponding subsystems > got serious rewrite. The current TTY code still uses destroy_dev_sched_cb(). In a very old version of the new TTY code, close() on a pseudo-terminal master device would also end up calling destroy_dev(), which meant it blocked until the TTY was closed as well, which is obviously not what it should do. I changed the TTY code to destroy_dev_sched_cb(), which means tty_gone() doesn't block. The TTY layer later calls a callback function, so the pts driver can deallocate the softc and reclaim the unit number (pts/%d). -- Ed Schouten WWW: http://80386.nl/ pgpd8uZdIRnXS.pgp Description: PGP signature
Re: Greetings... a patch I would like your comments on...
* Ivan Voras wrote: > Yes, I was thinking about WaitForMultipleObjects() - I sometimes > wished I had it in FreeBSD :) FreeBSD already has -- unfortunately it's only accessible from within the ndisulator. ;-) -- Ed Schouten WWW: http://80386.nl/ pgpsmWemswXTT.pgp Description: PGP signature
Re: Greetings... a patch I would like your comments on...
* Ivan Voras wrote: > This is a good and useful addition! I think Windows has implemented a > generalization of this (called "wait objects" or something like that), > which effectively allows a select()- (or in this case kqueue())-like > syscall to wait on both file descriptors and condvars (as well as > probably other MS-style objects). It's useful for multiplexing events > for dissimilar sources. NtWaitForSingleObject(), NtWaitForMultipleObjects(), etc. :-) -- Ed Schouten WWW: http://80386.nl/ pgptDg89wEz2X.pgp Description: PGP signature
Re: something fails with svn
* jhell wrote: > With those remarks I will leave it up to your honed skills to figure out. If you don't have anything constructive to say, please refrain from responding to any message on these lists. The purpose of these lists is to help each other. -- Ed Schouten WWW: http://80386.nl/ pgp8fp9Jo6ghQ.pgp Description: PGP signature
Re: something fails with svn
* jhell wrote: > Take a look at your git config. The problem lies there and is very > visible. After you are done fixing that re-read the whole email that > you posted. Would you mind sharing what causes the problem then, Sherlock Holmes? -- Ed Schouten WWW: http://80386.nl/ pgpMlOTMYupwl.pgp Description: PGP signature
Re: [Patch] Updated termcap entries for xterm
* Gary Jennejohn wrote: > On Thu, 10 Dec 2009 14:25:54 +0100 > Ed Schouten wrote: > > Any testers, before I commit this patch to HEAD? > > > > I tried it with a "real" xterm and mrxvt and see no regressions. However, > I didn't try it with a VT as xterm. I couldn't find any regressions either, so I just committed it to HEAD. It turns out it did improve the situation for Terminal.app a little, so I am going to MFC it after all. Thanks for {testing,reporting,etc}! -- Ed Schouten WWW: http://80386.nl/ pgp7XwgDaZf3G.pgp Description: PGP signature
[Patch] Updated termcap entries for xterm
* Ed Schouten wrote: > I just tried the patch, but when I run `make' in share/termcap, I get > the following: > > | gzip -cn termcap.5 > termcap.5.gz > | TERM=dumb TERMCAP=dumb: ex - > /store/home/ed/projects/freebsd-head/share/termcap/termcap.src < > /store/home/ed/projects/freebsd-head/share/termcap/reorder > | script, 36: Pattern not found > | script, 36: Ex command failed: pending commands discarded > | *** Error code 1 > | > | Stop in /store/home/ed/projects/freebsd-head/share/termcap. The attached patch should bring the entries up-to-date. Unfortunately it still seems the issue with Apple's Terminal.app is present, but that's just Apple's fault. Because of that, I don't see a reason (yet) to MFC this. Any testers, before I commit this patch to HEAD? -- Ed Schouten WWW: http://80386.nl/ Index: share/termcap/termcap.src === --- share/termcap/termcap.src (revision 200186) +++ share/termcap/termcap.src (working copy) @@ -2784,48 +2784,46 @@ :ts=\E_:fs=\E\\:ds=\E_\E\\:tc=screen: SW|screen-w|VT 100/ANSI X3.64 virtual terminal with 132 cols:\ :co#132:tc=screen: -# $Xorg: termcap,v 1.3 2000/08/17 19:55:10 cpqbld Exp $ +# $XTermId: termcap,v 1.78 2009/11/09 00:24:26 tom Exp $ # # Note: # termcap format is limited to 1023 characters. This set of descriptions # is a subset of the terminfo, since not all features can be fit into # that limit. The 'xterm' description supports color. The monochrome -# 'xtermm' drops color in favor of additional function keys. If you need -# both, use terminfo. +# 'xterm-mono' drops color in favor of additional function keys. If you +# need both, use terminfo. # # The 1023-character limit applies to each entry after resolving the # "tc=" strings. Some implementations may discount all or part of the # formatting characters in the entry (i.e., the backslash newline tab # colon). GNU termcap does not have this limit. # -# I checked the limits using ncurses "captoinfo -CrTv", which prints +# I checked the limits using ncurses "captoinfo -CrTUvx", which prints # the resolved length of each entry in a comment at the end - T.Dickey # -# $XFree86: xc/programs/xterm/termcap,v 3.28 2001/01/17 23:46:39 dawes Exp $ +xterm-new|modern xterm:\ + :*6=\EOF:@7=\EOF:F1=\E[23~:F2=\E[24~:K2=\EOE:Km=\E[M:\ + :k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:k5=\E[15~:k6=\E[17~:\ + :k7=\E[18~:k8=\E[19~:k9=\E[20~:k;=\E[21~:kH=\EOF:kI=\E[2~:\ + :kN=\E[6~:kP=\E[5~:kd=\EOB:kh=\EOH:kl=\EOD:kr=\EOC:ku=\EOA:\ + :tc=xterm-basic: # -xterm-xfree86|XFree86 xterm:\ - :k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:\ - :k5=\E[15~:k6=\E[17~:k7=\E[18~:k8=\E[19~:\ - :k9=\E[20~:k;=\E[21~:F1=\E[23~:F2=\E[24~:\ - :@7=\EOF:@8=\EOM:kI=\E[2~:\ - :kh=\EOH:kP=\E[5~:kN=\E[6~:\ - :ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:Km=\E[M:tc=xterm-basic: -# # This chunk is used for building the VT220/Sun/PC keyboard variants. -xterm-basic|xterm common (XFree86):\ - :li#24:co#80:am:kn#12:km:mi:ms:xn:AX:bl=^G:\ - :is=\E[!p\E[?3;4l\E[4l\E>:rs=\E[!p\E[?3;4l\E[4l\E>:le=^H:\ - :AL=\E[%dL:DL=\E[%dM:DC=\E[%dP:al=\E[L:dc=\E[P:dl=\E[M:\ - :UP=\E[%dA:DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:\ - :ho=\E[H:cd=\E[J:ce=\E[K:cl=\E[H\E[2J:cm=\E[%i%d;%dH:cs=\E[%i%d;%dr:\ - :im=\E[4h:ei=\E[4l:ks=\E[?1h\E=:ke=\E[?1l\E>:kD=\E[3~:kb=^H:\ - :sf=\n:sr=\EM:st=\EH:ct=\E[3g:sc=\E7:rc=\E8:\ - :eA=\E(B\E)0:as=\E(0:ae=\E(B:ml=\El:mu=\Em:up=\E[A:nd=\E[C:\ - :md=\E[1m:me=\E[m:mr=\E[7m:so=\E[7m:se=\E[27m:us=\E[4m:ue=\E[24m:\ - :ti=\E[?1049h:te=\E[?1049l:vi=\E[?25l:ve=\E[?25h:\ - :ut:Co#8:pa#64:op=\E[39;49m:AB=\E[4%dm:AF=\E[3%dm: +xterm-basic|modern xterm common:\ + :am:bs:km:mi:ms:ut:xn:AX:\ + :Co#8:co#80:kn#12:li#24:pa#64:\ + :AB=\E[4%dm:AF=\E[3%dm:AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:\ + :DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:ae=\E(B:al=\E[L:\ + :as=\E(0:bl=^G:cd=\E[J:ce=\E[K:cl=\E[H\E[2J:\ + :cm=\E[%i%d;%dH:cs=\E[%i%d;%dr:ct=\E[3g:dc=\E[P:dl=\E[M:\ + :ei=\E[4l:ho=\E[H:im=\E[4h:is=\E[!p\E[?3;4l\E[4l\E>:\ + :kD=\E[3~:kb=^H:ke=\E[?1l\E>:ks=\E[?1h\E=:le=^H:md=\E[1m:\ + :me=\E[m:ml=\El:mr=\E[7m:mu=\Em:nd=\E[C:op=\E[39;49m:\ + :rc=\E8:rs=\E[!p\E[?3;4l\E[4l\E>:sc=\E7:se=\E[27m:sf=^J:\ + :so=\E[7m:sr=\EM:st=\EH:te=\E[?1049l:ti=\E[?1049h:\ + :ue=\E[24m:up=\E[A:us=\E[4m:ve=\E[?12l\E[?25h:vi=\E[?25l:vs=\E[?12;25h: -# The xterm-xfree86 description has all of the features, but is not completely +# The xterm-new description has all of the features, but is not completely # compatible with vt220. If you are using a Sun or PC keyboard, set the # sunKeyboard resource to true: # + maps the editing keypad @@ -2835,68 +2833,91 @@ # + uses DEC-style control sequences for the application keypad. # xterm-vt220|xterm emulating vt220:\ - :kH=\E[4~::@7=\E[4~:*6=\E[4~:kh=\E[1~:Km=\E[M:tc=xterm-basic: + :*6=\E[4~:@7=\E[4~:K2=\EOu:Km=\E[M:kH=\E[4~:kh=\E[1~:\ + :tc=xterm-basic: xterm-24|xterms|vs100
Re: old/unupdated xterm entries in termcap db
* Gary Jennejohn wrote: > IIRC there was a patch in the original post which may be a good starting > point. I just tried the patch, but when I run `make' in share/termcap, I get the following: | gzip -cn termcap.5 > termcap.5.gz | TERM=dumb TERMCAP=dumb: ex - /store/home/ed/projects/freebsd-head/share/termcap/termcap.src < /store/home/ed/projects/freebsd-head/share/termcap/reorder | script, 36: Pattern not found | script, 36: Ex command failed: pending commands discarded | *** Error code 1 | | Stop in /store/home/ed/projects/freebsd-head/share/termcap. -- Ed Schouten WWW: http://80386.nl/ pgp2KFkHlrhPx.pgp Description: PGP signature
Re: old/unupdated xterm entries in termcap db
Hello Alexander, others, * Alexander Leidinger wrote: > The practical attitude should be coordinated with ed@ (CCed), as he > switched the console in 9-current to be an xterm, and AFAIR it does > not support as much colors as the real xterm. Maybe there is a > reason to not update it. So the idea is to make TERM=xterm use 256 colors? Even though I think having more colors would be awesome, I think many things would break. For example: - As Alexander mentioned, our console driver doesn't support more than 16 (well, 8 on the background) colors. Fortunately our implementation in HEAD smashes down the 256 colors back to 8, so it shouldn't cause any serious artifacts. Just a slight inconvenience. - I know Apple's Terminal.app for example doesn't support 256 colors and badly misinterprets the escape sequences, causing portions of the screen to blink (because the sequence to switch to one of the extended colors contains a 5, which is blink). But if someone is interested in updating the entries in the termcap file to something newer (but no 256 colors), please do! Patches welcome! I will even MFC it! Our current entry for xterm isn't entirely compatible with Apple's Terminal.app either. I've noticed that an Erase Line (EL, ^[[K) with xterm uses the terminal's selected attributes to blank the terminal, while Apple's implementation uses the default terminal attributes (i.e. black background). -- Ed Schouten WWW: http://80386.nl/ pgpj6FdeBfU5Y.pgp Description: PGP signature
Re: mmap(2) with MAP_ANON honouring offset although it shouldn't
* Alan Cox wrote: > For what it's worth, I believe that Solaris does the exact opposite. > They provide MAP_ANONYMOUS for compatibility. It seems like a good > idea for us to do the same. Something like this? Index: mman.h === --- mman.h (revision 198919) +++ mman.h (working copy) @@ -82,6 +82,9 @@ */ #defineMAP_FILE 0x /* map from file (default) */ #defineMAP_ANON 0x1000 /* allocated from memory, swap space */ +#ifndef _KERNEL +#defineMAP_ANONYMOUSMAP_ANON /* For compatibility. */ +#endif /* !_KERNEL */ /* * Extended flags -- Ed Schouten WWW: http://80386.nl/ pgprDCQBa0Gu9.pgp Description: PGP signature
Re: mmap(2) with MAP_ANON honouring offset although it shouldn't
* John Baldwin wrote: > Note that the spec doesn't cover MAP_ANON at all FWIW. Yes. I've noticed Linux also uses MAP_ANONYMOUS instead of MAP_ANON. They do provide MAP_ANON for compatibility, if I remember correctly. -- Ed Schouten WWW: http://80386.nl/ pgpxciIJov3Hf.pgp Description: PGP signature
Re: mmap(2) with MAP_ANON honouring offset although it shouldn't
Hi Alan, * Alan Cox wrote: > The standards for mmap(2) actually disallow values of "off" that are not a > multiple of the page size. > > See http://www.opengroup.org/onlinepubs/95399/functions/mmap.html for > the following: > Just by accident I saw they changed that behaviour in a newer version of the spec: http://www.opengroup.org/onlinepubs/9699919799/functions/mmap.html -- Ed Schouten WWW: http://80386.nl/ pgpTEroorKRPA.pgp Description: PGP signature
Re: help needed to fix contrib/ee crash/exit when receiving SIGWINCH
Hy Eygene, * Eygene Ryabinkin wrote: > Sent the patch to bug-ncur...@gnu.org. Do you think that I should > send it to Thomas directly as well? Probably not. bug-ncurses@ should be good enough. Thanks! -- Ed Schouten WWW: http://80386.nl/ pgp38kOKPpvEE.pgp Description: PGP signature
Re: help needed to fix contrib/ee crash/exit when receiving SIGWINCH
* Eygene Ryabinkin wrote: > The problem should be healed with the attached patch. Ah, thanks. I looked at this some time ago but I also discovered ncurses was to blame. I didn't have any time to look at it back then, so I obviously forgot. Have you sent it to Thomas Dickey as well? -- Ed Schouten WWW: http://80386.nl/ pgpFmrxtywjnm.pgp Description: PGP signature
Re: RFC: Big Makefile patch for WARNS settings
Hi Ulrich, * Ulrich Spörlein wrote: > Comments? Committers? Wouldn't it better to address the root of the problem while there? ;-) Index: number.c === --- number.c(revision 197852) +++ number.c(working copy) @@ -88,9 +88,7 @@ int lflag; int -main(argc, argv) - int argc; - char *argv[]; +main(int argc, char *argv[]) { int ch, first; char line[256]; @@ -275,7 +273,7 @@ pfract(len) int len; { - static char *pref[] = { "", "ten-", "hundred-" }; + static char const * const pref[] = { "", "ten-", "hundred-" }; switch(len) { case 1: -- Ed Schouten WWW: http://80386.nl/ pgpMcujHjChWW.pgp Description: PGP signature
Re: sysinstall colours
* Paul B Mahol wrote: > This have nothing to do with ncurses, colors you like simple can not > be displayed in current syscons(4) and making support for 256 colors > or even true bit color in sysinstall(so that it looks amazing in > konsole) is waste of time. Yes. As of recently, our terminal emulator gained 256 color support, but this gets smashed down to 8 colors, simply because Syscons cannot handle more than 16 foreground and 8 background colors. This is how colors are converted: http://80386.nl/pub/xterm-256.png http://80386.nl/pub/teken-256.png -- Ed Schouten WWW: http://80386.nl/ pgpXF0RI95vDp.pgp Description: PGP signature
Testers wanted: xterm-style emulator!
Hi folks, I just committed a small patch for the Syscons terminal emulator that allows you all to test an xterm-style terminal emulator without requiring any recompilation of your kernel (just make sure you run HEAD at r197481 or later). I am considering making the xterm-style emulator the default somewhere in the future, because it has the following advantages: - Even though a larger set of instructions is a pain to implement, it does reduce bandwidth. When you use the xterm-style emulator, applications can use things like scrolling regions to scroll selected parts of the screen. This means that applications like screen(1), minicom(1), vi(1) (read: apps with status lines at the top/bottom) don't need to generate massive amounts of data each time you need to scroll. - Because 99% of all graphical terminal emulators use xterm-style emulation as well, you can finally use tools like dtach(1) between the console and X11 without any problems. dtach(1) doesn't perform any terminal emulation. It just forwards data. - You can finally SSH/telnet/rlogin/cu/etc. to devices such as switches and other operating systems without getting artifacts or termcap issues. - It makes it easier for us to eventually get Unicode working. cons25 and Unicode is hard, because at least our termcap entry uses things like 8-bit CP437 box drawing (ACS). There are still some small things broken with the xterm-style emulator, but it shouldn't be too bad. I've been using it for more than half a year or so. Known issues are: - The cursor keys, F1 to F12, insert, delete, home, end, page up, page down, etc. may not always work as expected. I'll look into this soon. - Box drawing *should* work the way it did before, but if you load different fonts, it may display the incorrect glyphs. I don't consider this to be a real bug, because this problem also exists when using cons25. How to help out: - Make sure you run FreeBSD HEAD r197481 or later. - Log in on the console. - Run the following commands: printf '\033[=T' export TERM=xterm - Just do the stuff you normally do and report any rendering issues that show up. Please give a detailed explanation of the programs you ran and what you had to do to trigger the issue. You can also use applications like tee(1) to capture display output. - If you want to stop testing: printf '\033[=1T' export TERM=cons25 You can also activate the xterm-style emulation by default. All you need to do, is compile your kernel with options TEKEN_XTERM set. Be sure to update your /etc/ttys to list xterm instead of cons25. Thanks! -- Ed Schouten WWW: http://80386.nl/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Deprecating ps(1)s -w switch
* Adrian Penisoara wrote: > Maybe we should also think about compatibility with System V Unix / Linux > -- I have encountered quite a lot of scripts expecting "ps -ef" to give an > "all processes" output. It would not hurt to review what the Linux folks did > with their ps(1) -- it supports 3 kinds of options for UNIX/BSD/GNU flavors. In my opinion we should just implement ps(1) as documented in the POSIX Onlinepubs. If it turns out it lacks certain features we want, we could consider adding this to procstat(1) instead. I am of course too lazy to work on this. ;-) -- Ed Schouten WWW: http://80386.nl/ pgpcZxeT4pqza.pgp Description: PGP signature
Re: tree doesnt compile
* Marc Balmer wrote: > > Am 25.08.2009 um 13:23 schrieb Marc Balmer: > > >/usr/src/sys/modules/vesa/../../i386/isa/vesa.c: In function > >'vesa_set_mode': > >/usr/src/sys/modules/vesa/../../i386/isa/vesa.c:1117: error: > >duplicate case value > > > >anyone seeing this as well or is this a local f***up ? > > fwiw, problem is still there after 'make clean && make kernel' svn up ;-) -- Ed Schouten WWW: http://80386.nl/ pgpj3vfbw7jBz.pgp Description: PGP signature
Re: Deprecating ps(1)s -w switch
* Brian Somers wrote: > I recently closed bin/137647 and had second thoughts after Ivan (the > originator) challenged my reason for closing it. > > The suggestion is that ps's -w switch is a strange artifact that can > be safely deprecated. ps goes to great lengths to implement width > limitations, and any time I've seen people not using -ww has either > been a mistake or doesn't matter. Using 'cut -c1-N' is also a great > way of limiting widths if people really want that... > > I'd like to propose changing ps so that width limits are removed and > '-w' is deprecated - ignored for now with a note in the man page > saying that it will be removed in a future release. > > Does anyone have any objections to doing this? I don't propose > merging this back into stable/8. So ps(1) output can never be limited to the screen width? -- Ed Schouten WWW: http://80386.nl/ pgp2fY6nDMwf4.pgp Description: PGP signature
Re: CFT: Patch for the Xen console driver
* Ed Schouten wrote: > Are there any (8.0-)users here who can test the attached patch for me? No, there aren't. Well, I'll commit it to HEAD. If it turns out that it breaks stuff, I'll give the person who reports it a glass of beer if we ever meet in person. ;-) -- Ed Schouten WWW: http://80386.nl/ pgpGmwHL6AVYw.pgp Description: PGP signature
CFT: Patch for the Xen console driver
Hi folks, Today I was doing some cleanups to our kernel message/debug console code and I noticed we have only one driver in the tree that does some really spooky things with its console device, namely the Xen console driver. I did some cleanups and basically fixed the following: - It now uses the CONSOLE_DRIVER() way to declare a driver, instead of using CONS_DRIVER() (which has some arguments which are no-ops nowadays), which means we can remove CONS_DRIVER() entirely. - It doesn't use cn_checkc anymore. The driver had a cn_getc routine, but it was never being called, because it was overlapped by cn_checkc. cn_checkc is deprecated in favour of cn_getc, so I removed cn_getc and renamed cn_checkc to cn_getc. - It doesn't runtime patch the functions inside struct consdev anymore. I'm planning on changing the consdev code to disallow drivers to patch their own functions, because the structure containing them may be shared between multiple console devices. Because I don't have a system with Xen, I was only capable of compile-testing the driver. Are there any (8.0-)users here who can test the attached patch for me? Thanks! -- Ed Schouten WWW: http://80386.nl/ --- sys/dev/xen/console/console.c +++ sys/dev/xen/console/console.c @@ -45,17 +45,15 @@ static void xcons_force_flush(void); static void xencons_priv_interrupt(void *); -static cn_probe_t xccnprobe; -static cn_init_txccninit; -static cn_getc_txccngetc; -static cn_putc_txccnputc; -static cn_putc_txccnputc_dom0; -static cn_checkc_t xccncheckc; +static cn_probe_t xc_cnprobe; +static cn_init_txc_cninit; +static cn_term_txc_cnterm; +static cn_getc_txc_cngetc; +static cn_putc_txc_cnputc; #define XC_POLLTIME (hz/10) -CONS_DRIVER(xc, xccnprobe, xccninit, NULL, xccngetc, - xccncheckc, xccnputc, NULL); +CONSOLE_DRIVER(xc); static int xen_console_up; static boolean_t xc_start_needed; @@ -105,7 +103,7 @@ }; static void -xccnprobe(struct consdev *cp) +xc_cnprobe(struct consdev *cp) { cp->cn_pri = CN_REMOTE; sprintf(cp->cn_name, "%s0", driver_name); @@ -113,37 +111,19 @@ static void -xccninit(struct consdev *cp) +xc_cninit(struct consdev *cp) { CN_LOCK_INIT(cn_mtx,"XCONS LOCK"); } -int -xccngetc(struct consdev *dev) -{ - int c; - if (xc_mute) - return 0; - do { - if ((c = xccncheckc(dev)) == -1) { -#ifdef KDB - if (!kdb_active) -#endif -/* - * Polling without sleeping in Xen - * doesn't work well. Sleeping gives - * other things like clock a chance to - * run - */ -tsleep(&cn_mtx, PWAIT | PCATCH, -"console sleep", XC_POLLTIME); - } - } while(c == -1); - return c; + +static void +xc_cnterm(struct consdev *cp) +{ } -int -xccncheckc(struct consdev *dev) +static int +xc_cngetc(struct consdev *dev) { int ret = (xc_mute ? 0 : -1); @@ -162,17 +142,27 @@ } static void -xccnputc(struct consdev *dev, int c) +xc_cnputc_domu(struct consdev *dev, int c) { xcons_putc(c); } static void -xccnputc_dom0(struct consdev *dev, int c) +xc_cnputc_dom0(struct consdev *dev, int c) { HYPERVISOR_console_io(CONSOLEIO_write, 1, (char *)&c); } +static void +xc_cnputc(struct consdev *dev, int c) +{ + + if (xen_start_info->flags & SIF_INITDOMAIN) + xc_cnputc_dom0(dev, c); + else + xc_cnputc_domu(dev, c); +} + extern int db_active; static boolean_t xcons_putc(int c) @@ -226,10 +216,6 @@ { int error; - if (xen_start_info->flags & SIF_INITDOMAIN) { - xc_consdev.cn_putc = xccnputc_dom0; - } - xccons = tty_alloc(&xc_ttydevsw, NULL); tty_makedev(xccons, NULL, "xc%r", 0); @@ -388,7 +374,7 @@ tp = (struct tty *)v; tty_lock(tp); - while ((c = xccncheckc(NULL)) != -1) + while ((c = xc_cngetc(NULL)) != -1) ttydisc_rint(tp, c, 0); if (xc_start_needed) { pgpSduarhJMqE.pgp Description: PGP signature
Re: sosend() and mbuf
* Maslan wrote: > > Is it possible to call kern_open() from within a kernel thread anyway? > I think yes, It worked on the parent thread before creating a new kthread. > See OpenKETA source, its using the same approach. > > kern_open() depends on a file descriptor table, right? > Yes, it returns a fd in the curthread->td_retval[0], which i should > use within the same thread to deal with this file. Didn't someone (Jeff Roberson?) develop some nice in-kernel API for accessing files some years ago? Why not use that? -- Ed Schouten WWW: http://80386.nl/ pgp7d5bxMCH7X.pgp Description: PGP signature
Re: sosend() and mbuf
* Maslan wrote: > I'm getting crazy, > > I don't know why kern_open() works in the module's main thread, but > when I use it in another thread created by kthread_create() it crashes > the kernel ??? Is it possible to call kern_open() from within a kernel thread anyway? kern_open() depends on a file descriptor table, right? -- Ed Schouten WWW: http://80386.nl/ pgpgaWKDUkcc5.pgp Description: PGP signature
Re: sosend() and mbuf
Hi, * Maslan wrote: > man kthread says: > The kthread_create() function is used to create a kernel thread. The new > thread shares its address space with process 0, the swapper process, and ^^^ > runs in kernel mode only. > > However, when i checked the pid & tid of the new created thread it was > not the same as the parent nor as the proc0 & thread0 I am not sure, but sharing another process's address space doesn't have to imply it shares the same pid, right? -- Ed Schouten WWW: http://80386.nl/ pgpXXe3XfVaCt.pgp Description: PGP signature
Re: bsd.lib.mk question
Hi Gabor, * Gábor Kövesdán wrote: > I wonder if there's a conventional way of building _only_ shared > libraries using bsd.lib.mk. At default, it builds static, shared and > profiled libraries, which is a waste of time because I only need > shared libraries, which I use as on-demand loadable modules. > Adjusting _LIBS after the inclusion of bsd.lib.mk doesn't help and > there are no knobs to control the behaviour. What should I do? Be sure to look at the Makefiles used by the PAM modules (lib/libpam/modules). I guess NO_PROFILE and NO_INSTALLLIB should be sufficient. -- Ed Schouten WWW: http://80386.nl/ pgpW43ul3l3zL.pgp Description: PGP signature
Re: concurrent sysctl implementation
* Jeremie Le Hen wrote: > On Fri, Jul 24, 2009 at 01:56:49PM +0200, Ed Schouten wrote: > > * Jeremie Le Hen wrote: > > > On Fri, Jul 24, 2009 at 11:18:42AM +0300, Kostik Belousov wrote: > > > > On Fri, Jul 24, 2009 at 09:34:51AM +0200, Jeremie Le Hen wrote: > > > > > Hi Ed, > > > > > > > > > > Sorry for the late reply. > > > > > > > > > > On Sat, May 09, 2009 at 02:13:13PM +0200, Ed Schouten wrote: > > > > > > We probably could. I think I discussed this with Robert Watson some > > > > > > time > > > > > > ago and we could use things like ELF hints. But still, that doesn't > > > > > > prevent us from reaching this limitation later on. > > > > > > > > > > Can you elaborate a little? Are you talking about elf-hints.h? > > > > > I don't see where we can get randomness from it. > > > > > > > > The thing is called ELF auxillary information vector. It is used to > > > > supply some useful information for interpreter from the kernel, > > > > see include/machine/elf.h for AT_* entries. > > > > > > Ah ok, so the idea is to generate a new hint, for instance AT_RANDOM, > > > generated at link time, that will be used to fill the canary at exec(2) > > > time? > > > > Very short answer: yes! > > Ok thanks. But this would make stack protection useless for local > attacks on suid binaries that are world-readable since the attacker > could read the ELF aux vector and compute the canary. Wait wait wait. It seems you were only partially right (and Kostik corrected you): We could add AT_RANDOM, but this value will be filled in by the kernel when starting the process. This means the random value is not stored in the binary. -- Ed Schouten WWW: http://80386.nl/ pgpkPBdmMkXBL.pgp Description: PGP signature
Re: concurrent sysctl implementation
* Jeremie Le Hen wrote: > On Fri, Jul 24, 2009 at 11:18:42AM +0300, Kostik Belousov wrote: > > On Fri, Jul 24, 2009 at 09:34:51AM +0200, Jeremie Le Hen wrote: > > > Hi Ed, > > > > > > Sorry for the late reply. > > > > > > On Sat, May 09, 2009 at 02:13:13PM +0200, Ed Schouten wrote: > > > > We probably could. I think I discussed this with Robert Watson some time > > > > ago and we could use things like ELF hints. But still, that doesn't > > > > prevent us from reaching this limitation later on. > > > > > > Can you elaborate a little? Are you talking about elf-hints.h? > > > I don't see where we can get randomness from it. > > > > The thing is called ELF auxillary information vector. It is used to > > supply some useful information for interpreter from the kernel, > > see include/machine/elf.h for AT_* entries. > > Ah ok, so the idea is to generate a new hint, for instance AT_RANDOM, > generated at link time, that will be used to fill the canary at exec(2) > time? Very short answer: yes! -- Ed Schouten WWW: http://80386.nl/ pgpXiKMuleZca.pgp Description: PGP signature
Re: llvm/clang a tool chain or just a compiler for FreeBSD?
* Dag-Erling Smørgrav wrote: > "Shaowei Wang (wsw)" writes: > > So what's the direction? Are we going to cut off all the GNU compiler > > tool chains and use the llvm/clang when it's mature. > > Who's "we"? > > Anyway, LLVM *isn't* mature, and it probably won't be for years, if > ever, so there's no point in asking. Even though "if ever" sounds a little bit pessimistic, I agree. Unfortunately I'm busy working on other things the last couple of weeks/months, but the biggest problem with LLVM/Clang right now is that the latest release on the website is practically useless to us. I've been tracking SVN, but each time I decide to upgrade sources, I get yet another regression, which means I have to file bug reports. I think I already filed 50-60 bug reports. For some reason there has been a lot of talking, but no hacking. It takes a lot of work to maintain ClangBSD, at least more than I'm willing to spend on it right now. -- Ed Schouten WWW: http://80386.nl/ pgpEqIvO4wFjU.pgp Description: PGP signature
Re: llvm/clang a tool chain or just a compiler for FreeBSD?
Hi, * Shaowei Wang (wsw) wrote: > Recently I am playing the clangbsd i386 branch and it works. I've noticed > that clang using gcc to linking object code or even doing assembling. No, this is not true. It calls ld and as to do the linking/assembling. Some stuff in the clangbsd branch still gets built with GCC, because of regressions/missing features of Clang. Yours, -- Ed Schouten WWW: http://80386.nl/ pgptnm59yfc6O.pgp Description: PGP signature
Re: add missing content to locking.9 ?
Hi Benjamin, * Benjamin Kaduk wrote: > +.Tn POSIX > +semaphores provide ... it looks like you described the semaphores that are used in userspace. The Semaphores section of the locking(9) man page should describe in-kernel semaphores (kern_sema.c). They are implemented by a mutex and a conditional variable. Even though it's nice to have some utility functions in our kernel, I always wondered why we have them. There isn't a lot of code in the tree that uses them... -- Ed Schouten WWW: http://80386.nl/ pgpOgqL9PsgQs.pgp Description: PGP signature
Re: i386_set_ldt on FreeBSD 7.x amd64
Hi Steven, * Steven Hartland wrote: > When you say HEAD would that require an upgrade to 7-STABLE or 8-CURRENT? Right now HEAD (or head/ in SVN) is 8-CURRENT. RELENG_7 (or stable/7) is 7-STABLE. -- Ed Schouten WWW: http://80386.nl/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
[Probably interesting for us] libcompiler_rt
Hi all. I think I've probably mentioned dozens of times I've been working with some other people to get FreeBSD working with Clang in the base system. The LLVM people recently announced another project that may be interesting for us, which should be usable with both GCC and Clang: http://compiler-rt.llvm.org/ libcompiler_rt is a replacement for libgcc. According to the site it has some performance improvements over libgcc. I'm personally not really interested in those (as long as it's not slower), but the license seems to be a lot better. Looking at the code, it seems to do what it should do. Maybe it would just be a lot easier if we integrated all required symbols into our C library. Maybe I'm going to take a look at this, but there are also other projects which I should work on. Yours, -- Ed Schouten WWW: http://80386.nl/ pgpf7esNnCvhI.pgp Description: PGP signature
Re: good morning to all
* malathi selvaraj wrote: > i am new one to freeBSD, kindly guide me Sure. In order to be eligible to use FreeBSD, you must buy a license for $ 100,-. I expect this money to be transferred to my bank account as soon as possible. The IBAN number is: NL30ABNA0385823426 -- Ed Schouten WWW: http://80386.nl/ pgpvQ4FmCofVb.pgp Description: PGP signature
Re: Clang: now available from a SVN server near you!
* Pawel Worach wrote: > So runtime performance is on par with gcc, code size is a bit bigger > so there is still room for optimization in LLVM. I don't agree on the code size. Code size is comparable. I just did a quick ls through /bin. There also seem to be a lot of cases where Clang generates smaller binaries. Some time ago the binaries were indeed a lot bigger, but that turned out to be a bug in Clang, where a compiler flag had a wrong default value, namely the flag that determined whether zero-initialized data had to go in BSS or not. -- Ed Schouten WWW: http://80386.nl/ pgpiIiQ7wigBO.pgp Description: PGP signature
Clang: now available from a SVN server near you!
Good news everyone! As I mentioned at BSDCan, I was going to import my FreeBSD+Clang branch into SVN. Tuesday I finally had some time to do it, so here's the result: http://svn.freebsd.org/viewvc/base/projects/clangbsd/ You can now build your very own version of FreeBSD with Clang installed as /usr/bin/cc as follows: - Check out the clangbsd branch from our SVN repository: svn co svn://svn.freebsd.org/base/projects/clangbsd - Put this in /etc/src.conf: WITH_CLANG= WITH_CLANG_IS_CC= NO_WERROR= WERROR= - Just run `make buildworld' and `make installworld'. You probably don't want to install it on top of your running system. I strongly advise you to create a separate jail to do all your testing with. When using a jail, you probably want to add NO_FSCHG= to /etc/src.conf as well to keep `make installworld' happy. So far we've only done testing on amd64 and i386. A lot of ports are probably still broken. Caveat emptor. Beware of dog. Slippery when wet. -- Ed Schouten WWW: http://80386.nl/ pgpKj3sqhaAnX.pgp Description: PGP signature
Re: concurrent sysctl implementation
* John Baldwin wrote: > Well, in theory a bunch of "small" requests to SYSCTL_PROC() nodes that used > sysctl_wire_old() (or whatever it is called) could cause the amount of user > memory wired for sysctls to grow unbounded. Thus, allowing this limited > concurrency is a tradeoff as there is a minimal (perhaps only theoretical at > the moment) risk of removing the safety net. > > The patch is quite small, btw, because the locking for the sysctl tree > already > exists, and by using read locks, one can already allow concurrent sysctl > requests. There is no need to add any new locks or restructure the sysctl > tree, just to adjust the locking that is already present. It might be > clearer, in fact, to split the sysctl memory lock back out into a separate > lock. This would allow "small" sysctl requests to run concurrently with a > single "large" request whereas in my suggestion in the earlier e-mail, > the "large" request will block all other user requests until it finishes. > > I've actually gone ahead and done this below. Boohoo. I actually wanted jt to work on this, as a small exercise to figure out the way locking primitives work in the kernel. No problem, because I can think of dozens of other things. Is there a chance we can see this patch in 8.0? I like it that the memlock is being picked up before we pick up the sysctl lock itself, which makes a lot of sense. -- Ed Schouten WWW: http://80386.nl/ pgpoN9a9RYCSv.pgp Description: PGP signature
Re: concurrent sysctl implementation
Hi Lars, * Lars Engels wrote: > Why is sysctl used to get a random number? Can't we get a different > source for it? We probably could. I think I discussed this with Robert Watson some time ago and we could use things like ELF hints. But still, that doesn't prevent us from reaching this limitation later on. I think other people (Rink Springer) also reported this issue years ago, even before we had the stack protector enabled. -- Ed Schouten WWW: http://80386.nl/ pgpVkyVsCo8A2.pgp Description: PGP signature
Re: concurrent sysctl implementation
Hi, * vasanth raonaik wrote: > Hello Jt, > > I am a newbee in this alias. I am having a very basic question. It would be > really good if you could give me some of this information. > Could you please elaborate on what is the current architecture of sysctl > implementation and How the concurrency would benefit us. Right now sysctl is synchronized using the sysctl lock. The problem is that certain sysctls just block for a very long time (especially some of the GEOM ones). We also call sysctl when we execute new processes, to obtain a random number for the stack protector. This means we have quite a lot of contention on it. This lock needs to be there, because sysctls can be added and removed on demand. I think I discussed this with John Baldwin (right?) and I think we also have the issue that we cannot allow an unbounded amount of concurrent calls to sysctl, because sysctl wires memory. A solution would be to solve it as follows: - Use a semaphore, initialized to some insane high value to put an upper limit on the amount of concurrent sysctl calls. I'm not sure whether this is really needed. Maybe this issue is not as serious as we think it is. - Use an rw/rm/sxlock to protect the sysctl tree, but only pick up the lock when we traverse parts of the sysctl tree that has dynamically created entries. -- Ed Schouten WWW: http://80386.nl/ pgpVFgnEuH1Cq.pgp Description: PGP signature
Decreasiong default dcons poll hz
Hi all, I was just discussing with rwatson on IRC that the default polling frequency used by dcons may be a little too high. It's currently set to 100 Hz. I guess it should probably use 25 Hz at most. My question is if anyone using dcons could try decreasing kern.dcons.poll_hz to 25 and let me know whether that's still usable. Thanks! -- Ed Schouten WWW: http://80386.nl/ pgp89S74AyQMB.pgp Description: PGP signature
Re: How to increase the max pty's on Freebsd 7.0?
Hi Alex, * Wilkinson, Alex wrote: > > 0n Wed, Apr 01, 2009 at 10:53:06PM +0200, Ed Schouten wrote: > > >You can increase the maximum amount of PTYs by editing a lot of source > >files on your system. There is some good news: in -CURRENT we switched > >to Unix98-style PTYs (/dev/pts/%u). Right now the maximum amount of PTYs > >is limited to 1000 (0 to 999). > > What are "Unix98-style PTYs" ? Unix98-style PTYS is a name often given to implementations of pseudo-terminals that use a character device called /dev/ptmx to allocate a new pseudo-terminal. After /dev/ptmx has been opened, it will expose a new TTY in /dev/pts. The name of the TTY can be obtained using routines like ptsname(). Operating systems like Linux and Solaris use this as well. FreeBSD's pts(4) driver also has a /dev/ptmx character device, but it's just there for compatibility (Linux binary emulation, older -CURRENT libcs). The preferred way to allocate pseudo-terminals is to call posix_openpt(2). An advantage of the current design is that allocating pseudo-terminals can be done a lot more easily. On RELENG_[67] posix_openpt(3) is a libc routine that has to loop through devfs to search for the first unused pseudo-terminal. It also requires a set-uid utility (pt_chown) to change the ownership of the TTY: http://svn.freebsd.org/viewvc/base/stable/7/lib/libc/stdlib/grantpt.c?view=markup In -CURRENT the TTYs are allocated on demand with the proper permissions in place. -- Ed Schouten WWW: http://80386.nl/ pgpbZIg13TEfl.pgp Description: PGP signature
Re: How to increase the max pty's on Freebsd 7.0?
* Paul Schenkeveld wrote: > Or change 'pts' to, for example, 'pt' so without changing utmp and > related stuff we'll have space for a four digit pty number. I've noticed lots of apps already misbehave because of the pty(4) -> pts(4) migration. I guess using a new naming scheme would totally break stuff. There are lots of apps that do things like: if (strncmp(tty, "tty", 3) != 0 && strncmp(tty, "pts/", 4) != 0) printf("Not a valid pseudo-terminal!\n"); But those are just workarounds. Our utmp format is broken anyway. It's not just UT_LINESIZE that's too small. I think we received many complaints from people who want to increase UT_HOSTSIZE as well. -- Ed Schouten WWW: http://80386.nl/ pgpvuMfsX7ctx.pgp Description: PGP signature
Re: How to increase the max pty's on Freebsd 7.0?
* Ed Schouten wrote: > I also thought about that, but the risks are probably too high. I think > it's better to just redesign our utmp/wtmp/lastlog system. I guess we > could do something like this: I forgot one step: > - Implement utmpx. At first utmpx should just be a set of wrappers > around utmp/wtmp/lastlog. > - Migrate all applications to utmpx. - Remove ttyslot() and . > - Change the utmpx code to use some new fancy file format. -- Ed Schouten WWW: http://80386.nl/ pgpThQaEOytzg.pgp Description: PGP signature
Re: How to increase the max pty's on Freebsd 7.0?
Hi Kostik, * Kostik Belousov wrote: > Can we switch to %x ? Or even, use some radix encoding of the number, > to allow alphabetical symbols too ? I guess that would break a lot of existing libraries. For example: older RELENG_7/CURRENT libcs might still use TIOCGPTN. This ioctl just returns a number that is just printed into a device name using "/dev/pts/%u" as a format. I also suspect a lot of Linux/Solaris-minded software expects the names to be in decimal form. I also thought about that, but the risks are probably too high. I think it's better to just redesign our utmp/wtmp/lastlog system. I guess we could do something like this: - Implement utmpx. At first utmpx should just be a set of wrappers around utmp/wtmp/lastlog. - Migrate all applications to utmpx. - Change the utmpx code to use some new fancy file format. I think I can finish the first step before 8.0 if I start working on this one of these weeks. -- Ed Schouten WWW: http://80386.nl/ pgpJdd2GtY3g5.pgp Description: PGP signature
Re: How to increase the max pty's on Freebsd 7.0?
Hi Steven, * Steven Hartland wrote: > How can I increase the maximum number or ptys available on FreeBSD 7.0? > > It seems that currently the machine is maxing out at 512 but there is > still loads of capacity left on the machine. > > Ideally would like to double at least the number of ttys available, > any help would be most appreciated. You can increase the maximum amount of PTYs by editing a lot of source files on your system. There is some good news: in -CURRENT we switched to Unix98-style PTYs (/dev/pts/%u). Right now the maximum amount of PTYs is limited to 1000 (0 to 999). We're currently limited to 7 characters (pts/999) because our utmp/ wtmp/lastlog files only reserve 8 bytes for the TTY name. If you're brave enough, you can increase UT_LINESIZE in include/utmp.h and MAXPTSDEVS in sys/kern/tty_pts.c. Be sure to recompile everything and to remove your utmp/wtmp/lastlog files. -- Ed Schouten WWW: http://80386.nl/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] Support for thresholds in du(1)
* Mel wrote: > Example usage: > # du -xht 20m . > 29M./contrib/binutils > 52M./contrib/gcc > 237M./contrib > 35M./crypto > 28M./lib > 20M./share > 55M./sys/dev > 139M./sys > 545M. Ooh! That looks awesome! -- Ed Schouten WWW: http://80386.nl/ pgph7lwd43C6C.pgp Description: PGP signature
Re: fgetc doubts
* Gábor Kövesdán wrote: > Hello, > > I have a problem when reading files with fgetc when a 0xff character > comes. In my code the reading stops at that point as if EOF had been > reached, but that's not actually the case. > The code is here: > http://p4web.freebsd.org/@md=d&cd=//&c=Nsd@//depot/projects/soc2008/gabor_textproc/grep/file.c?ac=64&rev1=40 > And the problem occurs in grep_fgetln() when the buffers is being filled in: >for (; i < bufsiz && !grep_feof(f); i++) >binbuf[i] = grep_fgetc(f); > > Thanks in advance, Sign extension bug? -- Ed Schouten WWW: http://80386.nl/ pgpWJTZdWf3S9.pgp Description: PGP signature
Re: Spin down HDD after disk sync or before power off
* Daniel Thiele wrote: > Looking at the numbers in the Hitachi drive specifications Tobias an I > dug out from the Hitachi website (see replies in the Joerg Sonnenberger > branch of this thread) the normal Load/Unload count is about 30 times > higher than the Emergency Unload count. Have you also looked at the definition of `emergency unload'? Maybe this number doesn't actually refer to the number of unloads caused by power loss, but because they detect a very high amount of vibration. But I'm not a hard disk expert. -- Ed Schouten WWW: http://80386.nl/ pgpw0rtjASWXV.pgp Description: PGP signature
Re: hosted, or not (Re: Renaming all symbols in libmp(3))
* per...@pluto.rain.com wrote: > So perhaps one solution would be to compile libmp with -ffreestanding? And all applications that use . -- Ed Schouten WWW: http://80386.nl/ pgpwD14uSm0Hj.pgp Description: PGP signature
Re: Renaming all symbols in libmp(3)
* Daniel Eischen wrote: > Well, as long as you're in there, maybe you should add > symbol versioning anyway, even after a library version > bump. Seems like it would be easy since there aren't > that many symbols. I assume I should just mark all symbols with version FBSD_1.1? If so, the following patch should be good enough: http://80386.nl/pub/mp.diff -- Ed Schouten WWW: http://80386.nl/ pgphdbc8hCD4J.pgp Description: PGP signature
Re: Renaming all symbols in libmp(3)
* Daniel Eischen wrote: > Why don't you add symbol versioning to libmp, so that old > binaries will still work, but new ones will get the new > symbols by default. Hmm, will that work without bumping > SHLIB_MAJOR? You might want to play around with it and > see. Well, even without symbol versioning this could be done, by just making a __strong_reference() between the symbols, but I decided not to do so. I think solutions like these are perfect when just renaming/removing a couple of symbols, but because we're basically touching everything, I thought we'd better just use the old approach. -- Ed Schouten WWW: http://80386.nl/ pgpRgi8CMXTsD.pgp Description: PGP signature
Renaming all symbols in libmp(3)
Hello all, As you may have read some days ago, work has started to make the FreeBSD base system compile better with clang, the BSD licensed C compiler from the LLVM project. One of the reasons why we can't compile the base system yet, is because some applications in the base system (keyserv, newkey, chkey, libtelnet) won't compile, because a library they depend (libmp)on has a function called pow(). By default, LLVM has a built-in prototype of pow(), similar to GCC. Unlike GCC, LLVM raises a compiler error by default. The manual page also mentions this issue. After some talking on IRC, I think the best solution would be to rename all functions in libmp. Even though this may sound very awful at first, it seems the competition has done this as well: http://docs.sun.com/app/docs/doc/819-2246/mp-3mp?a=view I'm not saying that if the Solaris developers jump off a cliff, we should do the same, but looking at the amount of applications that depend on libmp (almost none), I think it's the only definitive solution. So this is the patch I propose to commit to SVN one of these days: http://80386.nl/pub/mp.diff Because this also reduces some warnings when compiling stuff with GCC, I've increased WARNS in various Makefiles. I've also increased the SHLIB_MAJOR and __FreeBSD_version. Any comments? -- Ed Schouten WWW: http://80386.nl/ pgpvxZAZH3Q4P.pgp Description: PGP signature
Re: x11 status
Hi Chuck, * Chuck Robey wrote: > I was wondering, I've lost track of the status of XFree86 on > FreeBSD.or really, at all. It looks like all of the Xfree86 servers > have been removed from ports. The XFree86 project has been dying ever since almost all the active development moved to the Xorg-project. Xorg has many new features that XFree86 doesn't have, like hardware compositing and improved device detection. > I was looking on the www.Xfree86.org website, and from what I see, it > apparently still is generating releases. Also, I downloaded the > latest cvs image from Xfree86, and it built FAR easier that xorg, far > faster, far simpler to configure ... Why should it matter how easy it is to build a piece of software? You can just run `make -C /usr/ports/x11/xorg install clean' or `pkg_add -r xorg'. > but when I look into FreeBSD-ports, the few ports which still have the > Xfree86 name, they're really cheating (talking about the drivers), > they seem to be really xorg drivers, just haven't had their names > fixed. This is a naming decision by the Xorg project. For some reason, all drivers are still called xf86-*. It's pretty hard to remove all references to XFree86 in hundreds of megabytes of source code. -- Ed Schouten WWW: http://80386.nl/ pgpr1WDGCTIPF.pgp Description: PGP signature
Re: pahole - Finding holes in kernel structs
* Max Laier wrote: > So to answer your first question, submitting 101 patches to rearrange 101 > structs is certainly a wasted effort. However, if you take a good look at > the > 2000 holes, identify an interesting subset and submit a patch to fix that > subset ... that would be a worthwhile effort ... IMHO. I guess it's also a wasted effort to reduce struct tty from 8xx to 7xx bytes, because it still allocates 1024 bytes of memory using malloc(9). I guess we should mainly focus on structures that are allocated using uma(9) or are slightly bigger than 2^n. -- Ed Schouten WWW: http://80386.nl/ pgpixDBOrX3k4.pgp Description: PGP signature
Re: Mackbook pro nvidia based video backlight
* Alexander Leidinger wrote: >> The ideal solution would be to integrate it into vidcontrol, calling >> some kind of ioctl on the TTY/consolectl, but syscons is too brainless >> to know anything about hardware specific features. > > Here we are back to what was proposed instead of sysctl. I have to admin > that I'm confused now about what you propose as a good solution. Well, I wouldn't like it if we create character devices, just to let it implement a single ioctl() ("/dev/backlight", for example). There is only 1 parameter that's adjustable, namely the backlight intensity. A sysctl is a good place to store such things. In my opinion we should only use character devices for devices that have the semantics of a file descriptor, namely to read/write data to it, perform select(), etc. Saying sysctl is bad, because it doesn't allow any permissions should be considered to be a defect of sysctl, not an advantage of devfs. The reason why I prefer consolectl, is because it already exists and allows related graphics parameters to be configured. -- Ed Schouten WWW: http://80386.nl/ pgpHpmCQvy4nL.pgp Description: PGP signature
Re: Mackbook pro nvidia based video backlight
* Alexander Leidinger wrote: > So you want that either > - a daemon running as root is written which listens to user >requests to set the backlight via sysctl > or > - a SUID root program is written that sets the backlight >via sysctl > instead of > - a character device with appropriate filesystem permissions >which allows to not go the SUID root or daemon running as >root way > ? Yes. The primary reason is that it is more consistent with the rest of the operating system. powerd also uses sysctl's instead of a character device, for example. The ideal solution would be to integrate it into vidcontrol, calling some kind of ioctl on the TTY/consolectl, but syscons is too brainless to know anything about hardware specific features. -- Ed Schouten WWW: http://80386.nl/ pgpMgbBaYMZZ3.pgp Description: PGP signature
Re: INTR_FILTER?
* Andriy Gapon wrote: > INTR_FILTER - what does it do? > It doesn't seem to be documented anywhere, but seems to affect interrupt > code. Not sure, but I think I was once told that FreeBSD has a `two level' interrupt handling scheme, where the filter is invoked directly to only figure out whether the interrupt is spurious or not. After it has been determined it is not, an interrupt thread is scheduled to handle the interrupt. But as I said, I'm not sure. :-) -- Ed Schouten WWW: http://80386.nl/ pgpZnYO2BZE25.pgp Description: PGP signature
Re: Mackbook pro nvidia based video backlight
* Rui Paulo wrote: > Not really. The xorg intel driver is already able to deal with this. > I don't know about NVIDIA. Yes, but that's what I mean. It will be a cold day in hell when "nv" supports this. As far as I can tell, it's just a pile of obfuscated C code. -- Ed Schouten WWW: http://80386.nl/ pgpfCdduX2rYB.pgp Description: PGP signature