Re: [RFC] last(1) with security.bsd.see_other_uids support
2012/6/5 Jilles Tjoelker jil...@stack.nl: 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 e...@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: [RFC] last(1) with security.bsd.see_other_uids support
2012/6/6 Pawel Jakub Dawidek p...@freebsd.org: 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 e...@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: [RFC] last(1) with security.bsd.see_other_uids support
Hi Bryan,
2012/6/4 Bryan Drewery br...@shatow.net:
* 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 e...@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
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 e...@80386.nl WWW: http://80386.nl/ - Forwarded message from Ed Schouten e...@freebsd.org - Date: Mon, 6 Feb 2012 10:23:11 + (UTC) From: Ed Schouten e...@freebsd.org 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
Hello Eitan, * Eitan Adler li...@eitanadler.com, 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 e...@80386.nl WWW: http://80386.nl/ pgpk2dytKI6SM.pgp Description: PGP signature
Re: dup3 syscall - atomic set O_CLOEXEC with dup2
* Ed Schouten e...@80386.nl, 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 e...@80386.nl WWW: http://80386.nl/ pgpABvOKMHAi3.pgp Description: PGP signature
Re: dup3 syscall - atomic set O_CLOEXEC with dup2
Hi Kostik,
* Kostik Belousov kostik...@gmail.com, 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 e...@80386.nl
WWW: http://80386.nl/
pgpKSAVj4LrZi.pgp
Description: PGP signature
Re: Communication between kernel and userspace via local socket
* Maxim Ignatenko gelraen...@gmail.com, 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 e...@80386.nl WWW: http://80386.nl/ pgpdZgbXYqVSE.pgp Description: PGP signature
Re: BUG: 'glabel label' name's lenght, is truncated without err/warn
* Lucas Holt l...@foolishgames.com, 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 e...@80386.nl
WWW: http://80386.nl/
pgpiTKtTnUUyN.pgp
Description: PGP signature
Re: BUG: 'glabel label' name's lenght, is truncated without err/warn
Hi Andrew, * Andrew Duane adu...@juniper.net, 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 e...@80386.nl WWW: http://80386.nl/ pgp3k0xKTMyC1.pgp Description: PGP signature
Re: [PATCH] avoid assuming MAXPATHLEN in config(8)
Hi Robert, * Robert Millan r...@debian.org, 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 e...@80386.nl WWW: http://80386.nl/ pgpSZpTBufHTD.pgp Description: PGP signature
Re: [PATCH] avoid assuming MAXPATHLEN in config(8)
* Robert Millan r...@debian.org, 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 e...@80386.nl WWW: http://80386.nl/ pgpCxVFvPVCKF.pgp Description: PGP signature
Re: [PATCH] build config(8) on GNU systems
* Robert Millan r...@debian.org, 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 e...@80386.nl
WWW: http://80386.nl/
pgpjq8GSwsoLs.pgp
Description: PGP signature
Re: [PATCH] build config(8) on GNU systems
* Zhihao Yuan lich...@gmail.com, 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 e...@80386.nl WWW: http://80386.nl/ pgpbqUUDWhNbF.pgp Description: PGP signature
Re: [PATCH] build config(8) on GNU systems
Fixed in r223744. Thanks! -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpBp8MHciKH9.pgp Description: PGP signature
Re: State of FreeBSD/xbox
Hi Chris, Kostik, * Kostik Belousov kostik...@gmail.com, 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 e...@80386.nl 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 e...@80386.nl 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 e...@80386.nl, 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 e...@80386.nl WWW: http://80386.nl/ pgpssyE3e4sFK.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 e...@80386.nl WWW: http://80386.nl/ pgpxtVH6ehp5C.pgp Description: PGP signature
Re: Tested wanted: BSD-licensed libgcc replacement, libcompiler_rt
* Ed Schouten e...@80386.nl, 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 e...@80386.nl WWW: http://80386.nl/ pgpbcBir7S44Y.pgp Description: PGP signature
Re: Examining the VM splay tree effectiveness
Andre, * Andre Oppermann an...@freebsd.org 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 e...@80386.nl 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 mubeeshal...@gmail.com 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 filename 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 e...@80386.nl WWW: http://80386.nl/ pgp7FCLPTM5t8.pgp Description: PGP signature
Re: A simple and hopefully usable FreeBSD live CD
* Lars Engels lars.eng...@0x20.net 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 e...@80386.nl WWW: http://80386.nl/ pgpff35ZrLT3j.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 e...@80386.nl WWW: http://80386.nl/ pgpApzTt0kvES.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 e...@80386.nl WWW: http://80386.nl/ freebsd-bootcd.tar.gz Description: Binary data pgpEq9MbOmBDP.pgp Description: PGP signature
Re: A simple and hopefully usable FreeBSD live CD
* Tim Judd taj...@gmail.com 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 e...@80386.nl WWW: http://80386.nl/ pgpqpSStEb5hy.pgp Description: PGP signature
Re: Data truncation on ptys
Hello Michael, * Michael Sperber sper...@deinprogramm.de 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 e...@80386.nl WWW: http://80386.nl/ pgpR8RWIRgJks.pgp Description: PGP signature
Re: Problem detecting and reacting to serial break
* Paul Thornton p...@prt.org 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 e...@80386.nl WWW: http://80386.nl/ pgp1PRCv6Lq6n.pgp Description: PGP signature
Re: sysctl way too slow
* Atom Smasher a...@smasher.org 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 e...@80386.nl WWW: http://80386.nl/ pgpcbRRsFxAZF.pgp Description: PGP signature
Re: an alternative to powerpoint
* Bakul Shah ba...@bitblocks.com 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 e...@80386.nl WWW: http://80386.nl/ pgpcJX5O25Jc4.pgp Description: PGP signature
Re: sysctl question
* Andreas Tobler andreast-l...@fgznet.ch 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 e...@80386.nl WWW: http://80386.nl/ pgpN5VezoVfCk.pgp Description: PGP signature
Re: inet_* functions in kernel?
Hi Bartosz, * Bartosz Marcin Kojak bar...@6bone.be 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 e...@80386.nl WWW: http://80386.nl/ pgpADusBRjZe7.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 arei...@bigpond.net.au 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 e...@80386.nl WWW: http://80386.nl/ pgpNgoKSxOgsT.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 m...@mired.org 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 e...@80386.nl WWW: http://80386.nl/ pgpn1LzLEWm9v.pgp Description: PGP signature
Re: Moving from FreeBSD7 to FreeBSD8 (cdev, minor, dev2unit)
* Dmitry Krivenok krivenok.dmi...@gmail.com 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 e...@80386.nl WWW: http://80386.nl/ pgpfWd3nM8l93.pgp Description: PGP signature
Re: making consmsgbuf_size a tunable?
Hello Matthew, * Matthew Jacob m...@feral.com 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 e...@80386.nl WWW: http://80386.nl/ pgpvMZK9ULhdP.pgp Description: PGP signature
Re: periodically save current time to time-of-day hardware
* Andriy Gapon a...@icyb.net.ua 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 e...@80386.nl WWW: http://80386.nl/ pgpJmVpQo0Ats.pgp Description: PGP signature
Re: periodically save current time to time-of-day hardware
* Andriy Gapon a...@icyb.net.ua wrote: + timeout(periodic_resettodr, NULL, 1800 * hz); By the way, wouldn't it be a little nicer to use callout(9)? -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpz0oTdiuq2Z.pgp Description: PGP signature
Re: Strange behavior of kernel module (output terminated)
* Dmitry Krivenok krivenok.dmi...@gmail.com 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 e...@80386.nl WWW: http://80386.nl/ pgpGL1yJgnhth.pgp Description: PGP signature
Re: tty or script(1) weirdness?
Hi Alfred,
* Alfred Perlstein alf...@freebsd.org 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 termios.h
| int
| main(int argc, char *argv[])
| {
|
| tcdrain(0);
| }
I'll see what I can do.
--
Ed Schouten e...@80386.nl
WWW: http://80386.nl/
pgpDNzomltaDM.pgp
Description: PGP signature
Re: tty or script(1) weirdness?
* Ed Schouten e...@80386.nl 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 e...@80386.nl WWW: http://80386.nl/ pgpo052DoqSPZ.pgp Description: PGP signature
Re: [patch] extending {amd64|i386} cpu info
Hello Alexander, * Alexander Best alexbes...@wwu.de 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 e...@80386.nl WWW: http://80386.nl/ pgpBjDIabfOKa.pgp Description: PGP signature
Re: Deadlock between GEOM and devfs device destroy and process exit.
Hi all, * Kostik Belousov kostik...@gmail.com 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 e...@80386.nl WWW: http://80386.nl/ pgpd8uZdIRnXS.pgp Description: PGP signature
Re: Greetings... a patch I would like your comments on...
* Ivan Voras ivo...@freebsd.org 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 e...@80386.nl WWW: http://80386.nl/ pgptDg89wEz2X.pgp Description: PGP signature
Re: Greetings... a patch I would like your comments on...
* Ivan Voras ivo...@freebsd.org 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 e...@80386.nl WWW: http://80386.nl/ pgpsmWemswXTT.pgp Description: PGP signature
Re: something fails with svn
* jhell jh...@dataix.net 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 e...@80386.nl WWW: http://80386.nl/ pgp8fp9Jo6ghQ.pgp Description: PGP signature
Re: something fails with svn
* jhell jh...@dataix.net 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 e...@80386.nl WWW: http://80386.nl/ pgpMlOTMYupwl.pgp Description: PGP signature
Re: old/unupdated xterm entries in termcap db
Hello Alexander, others, * Alexander Leidinger alexan...@leidinger.net 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 e...@80386.nl WWW: http://80386.nl/ pgpj6FdeBfU5Y.pgp Description: PGP signature
Re: old/unupdated xterm entries in termcap db
* Gary Jennejohn gary.jennej...@freenet.de 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 e...@80386.nl WWW: http://80386.nl/ pgp2KFkHlrhPx.pgp Description: PGP signature
[Patch] Updated termcap entries for xterm
* Ed Schouten e...@80386.nl 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 e...@80386.nl 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|24x80 xterm:\ - :li#24:\ - :tc=xterm: + :li#24:tc=xterm-old: xterm-65|65x80 xterm:\ - :li#65:tc=xterm: + :li#65:tc=xterm-old: xterm-bold|xterm
Re: [Patch] Updated termcap entries for xterm
* Gary Jennejohn gary.jennej...@freenet.de wrote:
On Thu, 10 Dec 2009 14:25:54 +0100
Ed Schouten e...@80386.nl 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 e...@80386.nl
WWW: http://80386.nl/
pgp7XwgDaZf3G.pgp
Description: PGP signature
Re: mmap(2) with MAP_ANON honouring offset although it shouldn't
* John Baldwin j...@freebsd.org 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 e...@80386.nl WWW: http://80386.nl/ pgpxciIJov3Hf.pgp Description: PGP signature
Re: mmap(2) with MAP_ANON honouring offset although it shouldn't
* Alan Cox a...@cs.rice.edu 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 e...@80386.nl WWW: http://80386.nl/ pgprDCQBa0Gu9.pgp Description: PGP signature
Re: mmap(2) with MAP_ANON honouring offset although it shouldn't
Hi Alan, * Alan Cox alan.l@gmail.com 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: snip 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 e...@80386.nl 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 rea-f...@codelabs.ru 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 e...@80386.nl WWW: http://80386.nl/ pgp38kOKPpvEE.pgp Description: PGP signature
Re: help needed to fix contrib/ee crash/exit when receiving SIGWINCH
* Eygene Ryabinkin rea-f...@codelabs.ru 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 e...@80386.nl WWW: http://80386.nl/ pgpFmrxtywjnm.pgp Description: PGP signature
Re: sysinstall colours
* Paul B Mahol one...@gmail.com 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 e...@80386.nl WWW: http://80386.nl/ pgpXF0RI95vDp.pgp Description: PGP signature
Re: RFC: Big Makefile patch for WARNS settings
Hi Ulrich,
* Ulrich Spörlein u...@spoerlein.net 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 e...@80386.nl
WWW: http://80386.nl/
pgpMcujHjChWW.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 e...@80386.nl 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
* Brian Somers br...@freebsd.org 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 e...@80386.nl WWW: http://80386.nl/ pgp2fY6nDMwf4.pgp Description: PGP signature
Re: tree doesnt compile
* Marc Balmer m...@msys.ch 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 e...@80386.nl WWW: http://80386.nl/ pgpj3vfbw7jBz.pgp Description: PGP signature
Re: Deprecating ps(1)s -w switch
* Adrian Penisoara a...@freebsd.ady.ro 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 e...@80386.nl WWW: http://80386.nl/ pgpcZxeT4pqza.pgp Description: PGP signature
Re: CFT: Patch for the Xen console driver
* Ed Schouten e...@80386.nl 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 e...@80386.nl 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 e...@80386.nl
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
Hi, * Maslan maslan...@gmail.com 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 e...@80386.nl WWW: http://80386.nl/ pgpXXe3XfVaCt.pgp Description: PGP signature
Re: sosend() and mbuf
* Maslan maslan...@gmail.com 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 e...@80386.nl WWW: http://80386.nl/ pgpgaWKDUkcc5.pgp Description: PGP signature
Re: sosend() and mbuf
* Maslan maslan...@gmail.com 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 e...@80386.nl WWW: http://80386.nl/ pgp7d5bxMCH7X.pgp Description: PGP signature
Re: bsd.lib.mk question
Hi Gabor, * Gábor Kövesdán ga...@kovesdan.org 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 e...@80386.nl WWW: http://80386.nl/ pgpW43ul3l3zL.pgp Description: PGP signature
Re: concurrent sysctl implementation
* Jeremie Le Hen jere...@le-hen.org 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 e...@80386.nl WWW: http://80386.nl/ pgpXiKMuleZca.pgp Description: PGP signature
Re: concurrent sysctl implementation
* Jeremie Le Hen jere...@le-hen.org wrote: On Fri, Jul 24, 2009 at 01:56:49PM +0200, Ed Schouten wrote: * Jeremie Le Hen jere...@le-hen.org 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 e...@80386.nl WWW: http://80386.nl/ pgpkPBdmMkXBL.pgp Description: PGP signature
Re: llvm/clang a tool chain or just a compiler for FreeBSD?
* Dag-Erling Smørgrav d...@des.no wrote: Shaowei Wang (wsw) wsw1w...@gmail.com 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 e...@80386.nl 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) wsw1w...@gmail.com 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 e...@80386.nl WWW: http://80386.nl/ pgptnm59yfc6O.pgp Description: PGP signature
Re: add missing content to locking.9 ?
Hi Benjamin, * Benjamin Kaduk ka...@mit.edu 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 e...@80386.nl WWW: http://80386.nl/ pgpOgqL9PsgQs.pgp Description: PGP signature
Re: i386_set_ldt on FreeBSD 7.x amd64
Hi Steven, * Steven Hartland kill...@multiplay.co.uk 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 e...@80386.nl 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 e...@80386.nl WWW: http://80386.nl/ pgpf7esNnCvhI.pgp Description: PGP signature
Re: good morning to all
* malathi selvaraj malathira...@gmail.com 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 e...@80386.nl WWW: http://80386.nl/ pgpvQ4FmCofVb.pgp Description: PGP signature
Re: Clang: now available from a SVN server near you!
* Pawel Worach pawel.wor...@gmail.com 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 e...@80386.nl 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 e...@80386.nl WWW: http://80386.nl/ pgpKj3sqhaAnX.pgp Description: PGP signature
Re: concurrent sysctl implementation
* John Baldwin j...@freebsd.org 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 e...@80386.nl WWW: http://80386.nl/ pgpoN9a9RYCSv.pgp Description: PGP signature
Re: concurrent sysctl implementation
Hi Lars, * Lars Engels lars.eng...@0x20.net 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 e...@80386.nl WWW: http://80386.nl/ pgpVkyVsCo8A2.pgp Description: PGP signature
Re: concurrent sysctl implementation
Hi, * vasanth raonaik vasanth.raon...@gmail.com 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 e...@80386.nl 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 e...@80386.nl WWW: http://80386.nl/ pgp89S74AyQMB.pgp Description: PGP signature
Re: How to increase the max pty's on Freebsd 7.0?
* Paul Schenkeveld fb-hack...@psconsult.nl 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 e...@80386.nl WWW: http://80386.nl/ pgpvuMfsX7ctx.pgp Description: PGP signature
Re: How to increase the max pty's on Freebsd 7.0?
Hi Alex, * Wilkinson, Alex alex.wilkin...@dsto.defence.gov.au 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 e...@80386.nl WWW: http://80386.nl/ pgpbZIg13TEfl.pgp Description: PGP signature
Re: How to increase the max pty's on Freebsd 7.0?
Hi Steven, * Steven Hartland kill...@multiplay.co.uk 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 e...@80386.nl 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: How to increase the max pty's on Freebsd 7.0?
Hi Kostik, * Kostik Belousov kostik...@gmail.com 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 e...@80386.nl WWW: http://80386.nl/ pgpJdd2GtY3g5.pgp Description: PGP signature
Re: How to increase the max pty's on Freebsd 7.0?
* Ed Schouten e...@80386.nl 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 utmp.h. - Change the utmpx code to use some new fancy file format. -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpThQaEOytzg.pgp Description: PGP signature
Re: [PATCH] Support for thresholds in du(1)
* Mel fbsd.hack...@rachie.is-a-geek.net 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 e...@80386.nl WWW: http://80386.nl/ pgph7lwd43C6C.pgp Description: PGP signature
Re: fgetc doubts
* Gábor Kövesdán ga...@freebsd.org 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=dcd=//c=Nsd@//depot/projects/soc2008/gabor_textproc/grep/file.c?ac=64rev1=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 e...@80386.nl WWW: http://80386.nl/ pgpWJTZdWf3S9.pgp Description: PGP signature
Re: Spin down HDD after disk sync or before power off
* Daniel Thiele dthi...@gmx.net 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. snip 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 e...@80386.nl WWW: http://80386.nl/ pgpw0rtjASWXV.pgp Description: PGP signature
Re: hosted, or not (Re: Renaming all symbols in libmp(3))
* per...@pluto.rain.com per...@pluto.rain.com wrote: So perhaps one solution would be to compile libmp with -ffreestanding? And all applications that use mp.h. -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpwD14uSm0Hj.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 e...@80386.nl WWW: http://80386.nl/ pgpvxZAZH3Q4P.pgp Description: PGP signature
Re: Renaming all symbols in libmp(3)
* Daniel Eischen deisc...@freebsd.org 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 e...@80386.nl WWW: http://80386.nl/ pgpRgi8CMXTsD.pgp Description: PGP signature
Re: Renaming all symbols in libmp(3)
* Daniel Eischen deisc...@freebsd.org 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 e...@80386.nl WWW: http://80386.nl/ pgphdbc8hCD4J.pgp Description: PGP signature
Re: x11 status
Hi Chuck, * Chuck Robey chu...@telenix.org 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 e...@80386.nl WWW: http://80386.nl/ pgpr1WDGCTIPF.pgp Description: PGP signature
Re: pahole - Finding holes in kernel structs
* Max Laier m...@love2party.net 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 e...@80386.nl WWW: http://80386.nl/ pgpixDBOrX3k4.pgp Description: PGP signature
Re: Mackbook pro nvidia based video backlight
* Alexander Leidinger alexan...@leidinger.net 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 e...@80386.nl WWW: http://80386.nl/ pgpHpmCQvy4nL.pgp Description: PGP signature
Re: INTR_FILTER?
* Andriy Gapon a...@icyb.net.ua 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 e...@80386.nl WWW: http://80386.nl/ pgpZnYO2BZE25.pgp Description: PGP signature
Re: Mackbook pro nvidia based video backlight
* Alexander Leidinger alexan...@leidinger.net 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 e...@80386.nl WWW: http://80386.nl/ pgpMgbBaYMZZ3.pgp Description: PGP signature
Re: Mackbook pro nvidia based video backlight
* Daniel Lannstrom o...@trekdanne.se wrote: I'm asking which method will be the best to interface the driver with userland applications? You might want to make it a character device driver. And write a small userland control program. Sysctl isn't really made for this kind of functionality. No. sysctl is good for doing stuff like this. An even better approach would be to integrate it to the X11 driver, but I guess it will be cold day in hell when this happens. -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgp27BNLrmNeG.pgp Description: PGP signature
