Re: OT: Stream structures in bzlib and zlib
Heiko Wundram (Beenic) wrote: Hey all! I'm currently working on a project using zlib and bzlib, and I'm currently slightly stomped by the fact that both define the input buffer in their stream structure as non-const. I think they're not defined as const just to maintain compatibility with old and/or broken compilers. libarchive treats them as const and has never had any problems from this. Cheers, Tim Kientzle ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ath0 will not associate
Michael W. Lucas wrote: Hi, Runing -current i386 as of February 19. Tried to use an ath wireless on my laptop, it wouldn't associate using: # ifconfig ath0 ssid GoAway wepkey 0xdeadbeef1234567890deadbeef wepmode on Set "wlandebug scan+auth+assoc", got the following in /var/log/messages. (I've trimmed to 100 lines, the remainder is more of the same. Any suggestions, folks? Proper next steps to debug? Thanks, ==ml Feb 21 09:45:57 stretchlimo kernel: ath0: mem 0x8800-0x8800 irq 17 at device 0.0 on cardbus0 Feb 21 09:45:57 stretchlimo kernel: ath0: [ITHREAD] Feb 21 09:45:57 stretchlimo kernel: ath0: using obsoleted if_watchdog interface Feb 21 09:45:57 stretchlimo kernel: ath0: Ethernet address: 00:80:c8:1f:8c:43 Feb 21 09:45:57 stretchlimo kernel: ath0: mac 5.6 phy 4.1 radio 0.0 Feb 21 09:47:34 stretchlimo kernel: ath0: ath_chan_set: unable to reset channel 40 (5200 Mhz, flags 0x140 hal flags 0x140) Not good. You don't indicate what channel the ap is using but presumably it's not 40.I see no other similar msgs so presumably this was a one time occurence? Did you eject the card mid-scan? Feb 21 09:47:34 stretchlimo kernel: ath0: detached Feb 21 09:47:38 stretchlimo kernel: ath0: mem 0x8800-0x8800 irq 17 at device 0.0 on cardbus0 Feb 21 09:47:38 stretchlimo kernel: ath0: [ITHREAD] Feb 21 09:47:38 stretchlimo kernel: ath0: using obsoleted if_watchdog interface Feb 21 09:47:38 stretchlimo kernel: ath0: Ethernet address: 00:80:c8:1f:8c:43 Feb 21 09:47:38 stretchlimo kernel: ath0: mac 5.6 phy 4.1 radio 0.0 Feb 21 09:47:44 stretchlimo kernel: ath0: detached Feb 21 11:03:36 stretchlimo kernel: ath0: mem 0x8800-0x8800 irq 17 at device 0.0 on cardbus0 Feb 21 11:03:36 stretchlimo kernel: ath0: [ITHREAD] Feb 21 11:03:36 stretchlimo kernel: ath0: using obsoleted if_watchdog interface Feb 21 11:03:36 stretchlimo kernel: ath0: Ethernet address: 00:80:c8:1f:8c:43 Feb 21 11:03:36 stretchlimo kernel: ath0: mac 5.6 phy 4.1 radio 0.0 Feb 21 11:09:40 stretchlimo kernel: ath0: ieee80211_check_scan: active scan, duration 2147483647, desired mode auto, flush Feb 21 11:09:40 stretchlimo kernel: ath0: ieee80211_start_scan: active scan, duration 2147483647, desired mode auto, flush Feb 21 11:09:40 stretchlimo kernel: ath0: scan set 1g, 6g, 11g, 7g, 52a, 56a, 60a, 64a, 36a, 40a, 44a, 48a, 2g, 3g, 4g, 5g, 8g, 9g, 10g, 149a, 153a, 157a, 161a, 165a, 50S, 58S, 152S, 160S dwell min 20 max 200 Feb 21 11:09:40 stretchlimo kernel: ath0: scan_next: chan 1b -> 1g [active, dwell min 20 max 200] Feb 21 11:09:40 stretchlimo kernel: ath0: scan_next: chan 1g -> 6g [active, dwell min 20 max 200] Feb 21 11:09:40 stretchlimo kernel: ath0: scan_next: chan 6g -> 11g [active, dwell min 20 max 200] Feb 21 11:09:41 stretchlimo kernel: ath0: scan_next: chan 11g -> 7g [active, dwell min 20 max 200] Feb 21 11:09:41 stretchlimo kernel: ath0: scan_next: chan 7g -> 52a [active, dwell min 20 max 200] Feb 21 11:09:41 stretchlimo kernel: ath0: scan_next: chan 52a -> 56a [active, dwell min 20 max 200] Feb 21 11:09:41 stretchlimo kernel: ath0: scan_next: chan 56a -> 60a [active, dwell min 20 max 200] Feb 21 11:09:41 stretchlimo kernel: ath0: scan_next: chan 60a -> 64a [active, dwell min 20 max 200] Feb 21 11:09:42 stretchlimo kernel: ath0: scan_next: chan 64a -> 36a [active, dwell min 20 max 200] Feb 21 11:09:42 stretchlimo kernel: ath0: scan_next: chan 36a -> 40a [active, dwell min 20 max 200] Feb 21 11:09:42 stretchlimo kernel: ath0: scan_next: chan 40a -> 44a [active, dwell min 20 max 200] Feb 21 11:09:42 stretchlimo kernel: ath0: scan_next: chan 44a -> 48a [active, dwell min 20 max 200] Feb 21 11:09:42 stretchlimo kernel: ath0: scan_next: chan 48a -> 2g [active, dwell min 20 max 200] Feb 21 11:09:43 stretchlimo kernel: ath0: scan_next: chan 2g -> 3g [active, dwell min 20 max 200] Feb 21 11:09:43 stretchlimo kernel: ath0: scan_next: chan 3g -> 4g [active, dwell min 20 max 200] Feb 21 11:09:43 stretchlimo kernel: ath0: scan_next: chan 4g -> 5g [active, dwell min 20 max 200] Feb 21 11:09:43 stretchlimo kernel: ath0: scan_next: chan 5g -> 8g [active, dwell min 20 max 200] Feb 21 11:09:43 stretchlimo kernel: ath0: scan_next: chan 8g -> 9g [active, dwell min 20 max 200] Feb 21 11:09:44 stretchlimo kernel: ath0: scan_next: chan 9g -> 10g [active, dwell min 20 max 200] Feb 21 11:09:44 stretchlimo kernel: ath0: scan_next: chan 10g -> 149a [active, dwell min 20 max 200] Feb 21 11:09:44 stretchlimo kernel: ath0: scan_next: chan 149a -> 153a [active, dwell min 20 max 200] Feb 21 11:09:44 stretchlimo kernel: ath0: scan_next: chan 153a -> 157a [active, dwell min 20 max 200] Feb 21 11:09:44 stretchlimo kernel: ath0: scan_next: chan 157a -> 161a [active, dwell min 20 max 200] Feb 21 11:09:45 stretchlimo kernel: ath0: scan_next: chan 161a -> 165a [active, dwell min 20 max 200] Feb 21 11:09:45 stretchlimo kernel: ath0: scan_next: chan 165a ->
Re: cool feature of dmesg.boot file
On Thu, Feb 21, 2008 at 10:29:40PM +0100, Bartosz Giza wrote: > Hi, > > I have found quite interesting feature on one of router that lately i have > taken to administer. > What i knew was that file /var/run/dmesg.boot holds data from kernel buffer > that is taken right after file system(s) are mounted. > Lately i have found that one router writes to this file data from kernel > buffer when system is going to reeboot. Below are few lines from this file. > What you can see are lines from kernel right before reeboot. I have never > seen > before such lines in this file. And this is quite interesting. Could anyone > tell me how can i achieve such funcionality on other systems ? I have tried > to find on google about this but i couldn't find anything similar to this. You can even see the panic message if it was the reason for reboot. This works on every system where the RAM is not cleared on reboot. For example on every alpha, on my old IBM notebook, on Soekris systems, on at least some Intel server boards, ... Just not on vanilla PC, because their BIOS clears the RAM contents, so the old dmesg buffer is lost on the next kernel start. x86 that don't clear the RAM exists, just as my notebook and Soekris, but those are not very common. It is nothing which is configuriable though. Of course you could ask your board vendor to send you a less destructive BIOS, but I don't expect any positive result from that. I guess the main reason for this is that most are using the same BIOS framework and don't think about it. > -- > Waiting (max 60 seconds) for system process `vnlru' to stop...done > Waiting (max 60 seconds) for system process `bufdaemon' to stop...done > Waiting (max 60 seconds) for system process `syncer' to stop... > Syncing disks, vnodes remaining...2 2 2 0 0 done > All buffers synced. > GEOM_MIRROR: Device gm0: provider mirror/gm0 destroyed. > GEOM_MIRROR: Device gm0 destroyed. > Uptime: 71d13h58m11s > Copyright (c) 1992-2007 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 6.2-RELEASE #0: Sun Feb 18 20:05:19 CET 2007 > -- > > -- > Pozdrawiam > Bartosz Giza > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
cool feature of dmesg.boot file
Hi, I have found quite interesting feature on one of router that lately i have taken to administer. What i knew was that file /var/run/dmesg.boot holds data from kernel buffer that is taken right after file system(s) are mounted. Lately i have found that one router writes to this file data from kernel buffer when system is going to reeboot. Below are few lines from this file. What you can see are lines from kernel right before reeboot. I have never seen before such lines in this file. And this is quite interesting. Could anyone tell me how can i achieve such funcionality on other systems ? I have tried to find on google about this but i couldn't find anything similar to this. -- Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...2 2 2 0 0 done All buffers synced. GEOM_MIRROR: Device gm0: provider mirror/gm0 destroyed. GEOM_MIRROR: Device gm0 destroyed. Uptime: 71d13h58m11s Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-RELEASE #0: Sun Feb 18 20:05:19 CET 2007 -- -- Pozdrawiam Bartosz Giza ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /boot/loader graphics support & extensibility
On Feb 21, 2008, at 2:09 AM, Oliver Fromme wrote: Actually I don't plan to use a bitblit function at all, because it's not really feasible in standard VGA modes. What do you mean by that? Maybe we have different understandings what bitblit means. My understanding is that bitblit is a raster operation between two bitmaps (typically "AND" and "OR" operations for masking regions). I've done such things on the Amiga 20 years ago (hardware-assisted by a coprocessor called "Blitter"). I think they may fundamentally be the same thing. The bitblt I refer to is Bit Block Transfer. While the bitblt API could support bit-wise operations while it's copying, it's main purpose is to move a bit-array (tile/sprite) from RAM to VRAM, or possibly between VRAM locations. Everything that needs to be done can be done with a bitblt. It also happens to be the operation that was first accelerated... The abstraction is in the details of how a bit-mask or image map needs to be written to VRAM to have it appear as a char. or an image on the screen. I implemented bitblt for VGA for vtc(4). Take a look at: http://people.freebsd.org/~marcel/vga.diff [patch extracted from the tty branch in Perforce] That's good code, but how does it help abstracting the hardware? I think I might just fail to see the obvious because I haven't had enough coffee in the morning yet. The higher lever TTY code simply calls bitblt with a bit mask of the glyph to be printed and doesn't need to know about the details of the display. As such, simple console output works at any resolution and with any color depth. At the same time the VGA driver is abstracted from any high-level details, like fonts or character sets. This means that it's easy to write an accelerated driver for some graphics hardware. You simply implement mode setting and bitblt and you're good to go. For example, lets say there's a function to draw a rectangle (in fact there _is_ such a function in my code). The Forth code to draw a rectangle covering the whole screen at 640x480 would look like this: 480 640 0 0 vrect The FICL word pops the parameters from the Forth stack and calls a function gfx_rect(). This will go through an abstraction switch so it calls an appropriate function depending on the bitmap format of the current mode, i.e. there will be gfx_planar4_rect(), gfx_linear8_rect() and gfx_true24_rect(). Each of these functions implements the graphics operation in the most efficient way for the particular bitmap format. How would the above work with a bitblit function, exactly? You bitblt the 4 edges. I didn't say it was the most performance optimal thing to do. I only said that it can be abstracted that way. Rectangles are better abstracted with a linedraw primitive, but unless you really want generic line drawing capabilities in the loader, it's probably not worth implementing it That would be possible. But then there will be other problems. For example, lets say that the i386 loader decides to use 640x480 @4bit, and the sparc64 loader decides that 1152x900 @8bit is "best". The Forth code clearly needs a way to query the resolution and bit depth that was set, so it can chose an appropriate background image. It might also have to chose a different font. Yes, that's generally the difficulty with graphics. So the bottom line is that the Forth code cannot easily be abstracted from the hardware anyway. Well, it cannot be abstracted from the graphics settings, but it is abstracted from the hardware. True. I agree. What I meant to say was this: The hardware dictates which graphics settings are available. So the Forth code depends on the hardware indirectly. But of course it shouldn't have to know anything about the hardware itself. Yes. My vtc(4) driver, which puts graphics support in the kernel, is having the same problems with bitmaps. I have a nice logo (the 4.4 daemon: see http://www.mckusick.com/beastie/shirts/source.html), but I only have it for the standard VGA 4-bit color mode. I need a separate one for 16-bit and/or 256-bit colors... There's also a problem when VESA support is added: It's not possible to reliable detect what resolutions the attached monitor supports, so by default we must use 640x480 anyway, even if VESA support is present and the hardware can do 1600x1200 or whatever. Using a higher- resolution mode is a decision that needs to be made by the admin, not by the loader, so there must be a way for the Forth code to request a specific resolution. This does not have to be done in Forth. If in Forth you simply say "Switch to graphics" and the platform code looks up an environment variable for the actual mode, then the user is still control of the resolution. In fact, this is much more user friendly than having the user edit Forth code, which he/she may not... You're completely right, of course. I didn't mean to say the the user will have to edit Forth code (I wish loader would use a different language,
Re: encrypted executables
[EMAIL PROTECTED] wrote: > ari edelkind <[EMAIL PROTECTED]> writes: > > Keep in mind that ptrace(PT_ATTACH,...) will fail if a process is > > already being traced. As for core files, a process can use > > setrlimit(RLIMIT_CORE,...) to disable core dumps, and individual memory > > pages may be encrypted or unloaded, to be decrypted or loaded on > > demand. > > The person running the application can trivially replace ktrace(), > ptrace() and setrlimit() with non-functional stubs using LD_PRELOAD. And any application that executes its own code before running the system's dynamic loader -- or is statically linked, for that matter -- is free to unset LD_PRELOAD. There are many attack vectors. There are plenty of countermeasures. There are numerous attacks on each countermeasure. It goes on. This is all common knowledge, even among those creating anti-reverse-engineering techniques; in fact, it's usually prominently stated in an included disclaimer. It's unfortunate to note that, in many countries these days, the most effective deterrent against attacks on binary encryption is legal action. Some corporations add just-in-time page decryption to their binaries specifically for this recourse (e.g., against a competitor who creates applications that hook into the original software). ari ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: encrypted executables
Dag-Erling Smørgrav wrote: > ari edelkind <[EMAIL PROTECTED]> writes: > > Keep in mind that ptrace(PT_ATTACH,...) will fail if a process is > > already being traced. As for core files, a process can use > > setrlimit(RLIMIT_CORE,...) to disable core dumps, and individual memory > > pages may be encrypted or unloaded, to be decrypted or loaded on > > demand. > > The person running the application can trivially replace ktrace(), > ptrace() and setrlimit() with non-functional stubs using LD_PRELOAD. Right. And for a static binary (which doesn't respect LD_PRELOAD), it's fairly trivial to patch the syscalls so they're a no-op when called from the binary. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd In my experience the term "transparent proxy" is an oxymoron (like jumbo shrimp). "Transparent" proxies seem to vary from the distortions of a funhouse mirror to barely translucent. I really, really dislike them when trying to figure out the corrective lenses needed with each of them. -- R. Kevin Oberman, Network Engineer ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: OT: Stream structures in bzlib and zlib
On Thu, Feb 21, 2008 at 10:53:15AM +0100, Heiko Wundram (Beenic) wrote: > Before I go and test whether bzlib modifies the input buffer for temporaries > (by simply passing it data in a RO segment and checking whether I get a > SIGSEGV), is there anyone out there who's hit the same "problem" before and > might shed some more insight whether I'll have to copy the data before > setting it up in a stream structure as input? The buffers are not modified for the compression path. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: encrypted executables
ari edelkind <[EMAIL PROTECTED]> writes: > Keep in mind that ptrace(PT_ATTACH,...) will fail if a process is > already being traced. As for core files, a process can use > setrlimit(RLIMIT_CORE,...) to disable core dumps, and individual memory > pages may be encrypted or unloaded, to be decrypted or loaded on > demand. The person running the application can trivially replace ktrace(), ptrace() and setrlimit() with non-functional stubs using LD_PRELOAD. Ensuring that LD_PRELOAD is invisible to the application is left as an exercise to the reader. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: encrypted executables
"Thiago Damas" <[EMAIL PROTECTED]> writes: > And if you make a wrapper, and execute like a shell script: > > #!/usr/local/bin/mysecyritywrapper > <...encryted code goes where...> > > In this way. it'll be hard to use truss, ktrace, strace etc... Uh, no, not at all. Not even a little. Hint: 'ktrace -i'. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ath0 will not associate
Hi, Runing -current i386 as of February 19. Tried to use an ath wireless on my laptop, it wouldn't associate using: # ifconfig ath0 ssid GoAway wepkey 0xdeadbeef1234567890deadbeef wepmode on Set "wlandebug scan+auth+assoc", got the following in /var/log/messages. (I've trimmed to 100 lines, the remainder is more of the same. Any suggestions, folks? Proper next steps to debug? Thanks, ==ml Feb 21 09:45:57 stretchlimo kernel: ath0: mem 0x8800-0x8800 irq 17 at device 0.0 on cardbus0 Feb 21 09:45:57 stretchlimo kernel: ath0: [ITHREAD] Feb 21 09:45:57 stretchlimo kernel: ath0: using obsoleted if_watchdog interface Feb 21 09:45:57 stretchlimo kernel: ath0: Ethernet address: 00:80:c8:1f:8c:43 Feb 21 09:45:57 stretchlimo kernel: ath0: mac 5.6 phy 4.1 radio 0.0 Feb 21 09:47:34 stretchlimo kernel: ath0: ath_chan_set: unable to reset channel 40 (5200 Mhz, flags 0x140 hal flags 0x140) Feb 21 09:47:34 stretchlimo kernel: ath0: detached Feb 21 09:47:38 stretchlimo kernel: ath0: mem 0x8800-0x8800 irq 17 at device 0.0 on cardbus0 Feb 21 09:47:38 stretchlimo kernel: ath0: [ITHREAD] Feb 21 09:47:38 stretchlimo kernel: ath0: using obsoleted if_watchdog interface Feb 21 09:47:38 stretchlimo kernel: ath0: Ethernet address: 00:80:c8:1f:8c:43 Feb 21 09:47:38 stretchlimo kernel: ath0: mac 5.6 phy 4.1 radio 0.0 Feb 21 09:47:44 stretchlimo kernel: ath0: detached Feb 21 11:03:36 stretchlimo kernel: ath0: mem 0x8800-0x8800 irq 17 at device 0.0 on cardbus0 Feb 21 11:03:36 stretchlimo kernel: ath0: [ITHREAD] Feb 21 11:03:36 stretchlimo kernel: ath0: using obsoleted if_watchdog interface Feb 21 11:03:36 stretchlimo kernel: ath0: Ethernet address: 00:80:c8:1f:8c:43 Feb 21 11:03:36 stretchlimo kernel: ath0: mac 5.6 phy 4.1 radio 0.0 Feb 21 11:09:40 stretchlimo kernel: ath0: ieee80211_check_scan: active scan, duration 2147483647, desired mode auto, flush Feb 21 11:09:40 stretchlimo kernel: ath0: ieee80211_start_scan: active scan, duration 2147483647, desired mode auto, flush Feb 21 11:09:40 stretchlimo kernel: ath0: scan set 1g, 6g, 11g, 7g, 52a, 56a, 60a, 64a, 36a, 40a, 44a, 48a, 2g, 3g, 4g, 5g, 8g, 9g, 10g, 149a, 153a, 157a, 161a, 165a, 50S, 58S, 152S, 160S dwell min 20 max 200 Feb 21 11:09:40 stretchlimo kernel: ath0: scan_next: chan 1b -> 1g [active, dwell min 20 max 200] Feb 21 11:09:40 stretchlimo kernel: ath0: scan_next: chan 1g -> 6g [active, dwell min 20 max 200] Feb 21 11:09:40 stretchlimo kernel: ath0: scan_next: chan 6g -> 11g [active, dwell min 20 max 200] Feb 21 11:09:41 stretchlimo kernel: ath0: scan_next: chan 11g -> 7g [active, dwell min 20 max 200] Feb 21 11:09:41 stretchlimo kernel: ath0: scan_next: chan 7g -> 52a [active, dwell min 20 max 200] Feb 21 11:09:41 stretchlimo kernel: ath0: scan_next: chan 52a -> 56a [active, dwell min 20 max 200] Feb 21 11:09:41 stretchlimo kernel: ath0: scan_next: chan 56a -> 60a [active, dwell min 20 max 200] Feb 21 11:09:41 stretchlimo kernel: ath0: scan_next: chan 60a -> 64a [active, dwell min 20 max 200] Feb 21 11:09:42 stretchlimo kernel: ath0: scan_next: chan 64a -> 36a [active, dwell min 20 max 200] Feb 21 11:09:42 stretchlimo kernel: ath0: scan_next: chan 36a -> 40a [active, dwell min 20 max 200] Feb 21 11:09:42 stretchlimo kernel: ath0: scan_next: chan 40a -> 44a [active, dwell min 20 max 200] Feb 21 11:09:42 stretchlimo kernel: ath0: scan_next: chan 44a -> 48a [active, dwell min 20 max 200] Feb 21 11:09:42 stretchlimo kernel: ath0: scan_next: chan 48a -> 2g [active, dwell min 20 max 200] Feb 21 11:09:43 stretchlimo kernel: ath0: scan_next: chan 2g -> 3g [active, dwell min 20 max 200] Feb 21 11:09:43 stretchlimo kernel: ath0: scan_next: chan 3g -> 4g [active, dwell min 20 max 200] Feb 21 11:09:43 stretchlimo kernel: ath0: scan_next: chan 4g -> 5g [active, dwell min 20 max 200] Feb 21 11:09:43 stretchlimo kernel: ath0: scan_next: chan 5g -> 8g [active, dwell min 20 max 200] Feb 21 11:09:43 stretchlimo kernel: ath0: scan_next: chan 8g -> 9g [active, dwell min 20 max 200] Feb 21 11:09:44 stretchlimo kernel: ath0: scan_next: chan 9g -> 10g [active, dwell min 20 max 200] Feb 21 11:09:44 stretchlimo kernel: ath0: scan_next: chan 10g -> 149a [active, dwell min 20 max 200] Feb 21 11:09:44 stretchlimo kernel: ath0: scan_next: chan 149a -> 153a [active, dwell min 20 max 200] Feb 21 11:09:44 stretchlimo kernel: ath0: scan_next: chan 153a -> 157a [active, dwell min 20 max 200] Feb 21 11:09:44 stretchlimo kernel: ath0: scan_next: chan 157a -> 161a [active, dwell min 20 max 200] Feb 21 11:09:45 stretchlimo kernel: ath0: scan_next: chan 161a -> 165a [active, dwell min 20 max 200] Feb 21 11:09:45 stretchlimo kernel: ath0: scan_next: chan 165a -> 50S [active, dwell min 20 max 200] Feb 21 11:09:45 stretchlimo kernel: ath0: scan_next: chan 50S -> 58S [active, dwell min 20 max 200] Feb 21 11:09:45 stretchlimo kernel: ath0: scan_next: chan 58S -> 152S [active, dwell min 2
OpenBSM & Jails
hello i am using OpenBSM on System with jails part of praudit output / action write file in jail -- header,176,10,open(2) - write,creat,trunc,0,Thu Feb 21 13:45:06 2008, + 501 msec,argument,3,0x81ed,mode,argument,2,0x601,flags,path,//site/svn/dev.lineage2.dom/pamm/hooks/post-commit,attribute,755,www,www,88,800911,3234053,subject,lynx,root,wheel,root,wheel,44680,44668,56876,10.15.1.116,return,success,4,trailer,176, -- please add jail-identification in output (cat /dev/auditpipe | praudit -lp) /Vladimir Ermakov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Synaptics
Cristian, good day. Thu, Feb 21, 2008 at 01:57:08AM +0200, Cristian KLEIN wrote: >> Yes, please, try the mentioned patch and report back ;)) > > Sorry for the really long delay. No problems ;)) > The patch works perfectly on my Fujitsu-Siemens V5545. Thanks for the report! Norikatsu already kindly committed my patch, so you can update your ports and rebuild Synaptics driver -- it should work too and you'll not miss the modifications. -- Eygene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /boot/loader graphics support & extensibility
Marcel Moolenaar wrote: > On Feb 20, 2008, at 12:08 PM, Oliver Fromme wrote: > > By the way: Will the standard i386 /boot/loader work > > on an EFI machine, or does it require a different loader > > binary? > > It needs a different loader. If you want to support EFI > the right way, it also needs a different kernel -- one > that respects the memory map. But that's a different > story :-) OK. > > One final question: What happens if you try to call a > > BIOS interrupt (such as the 0x10 video interrupt) on > > an EFI machine? Will it crash? Or is there a > > compatibility layer that returns "not supported"? > > Assume it will crash. OK. That question was just out of curiosity. I assume such a situation will not arise in practice. > > > I haven't looked at the code yet, so I don't know > > > which graphics functions we're talking about. > > > > Here's an excerpt from the .h file (it's not complete): > > > > voidgfx_setcolor(int index, int color); > > voidgfx_setrgb(int color, int red, int green, int blue); > > voidgfx_usecolor(int color); > > voidgfx_pixel(int x, int y); > > voidgfx_rect(int x, int y, int width, int height); > > voidgfx_line(int x1, int y1, int x2, int y2); > > voidgfx_triangle(int x1, int y1, int x2, int y2, int x3, int y3); > > voidgfx_circle(int x, int y, int diameter); > > struct fontinfo *gfx_loadfont(char *filename); > > voidgfx_text(int *x, int *y, unsigned char *text, int length); > > unsigned char *gfx_loadpcx(char *filename); > > voidgfx_showpcx(unsigned char *pcx, int xstart, int ystart); > > > > > You may want to keep in mind that EFI basically > > > defines a single graphics function: bitblt. If the > > > graphics functions are variations of bitblt, then > > > yes, it's very reasonable. > > > > Actually I don't plan to use a bitblit function at all, > > because it's not really feasible in standard VGA modes. > > What do you mean by that? Maybe we have different understandings what bitblit means. My understanding is that bitblit is a raster operation between two bitmaps (typically "AND" and "OR" operations for masking regions). I've done such things on the Amiga 20 years ago (hardware-assisted by a coprocessor called "Blitter"). I don't see how such functionality helps in this situation, i.e. abstracting graphics functions from the hardware. > I implemented bitblt for VGA for vtc(4). Take a look at: > http://people.freebsd.org/~marcel/vga.diff > > [patch extracted from the tty branch in Perforce] That's good code, but how does it help abstracting the hardware? I think I might just fail to see the obvious because I haven't had enough coffee in the morning yet. For example, lets say there's a function to draw a rectangle (in fact there _is_ such a function in my code). The Forth code to draw a rectangle covering the whole screen at 640x480 would look like this: 480 640 0 0 vrect The FICL word pops the parameters from the Forth stack and calls a function gfx_rect(). This will go through an abstraction switch so it calls an appropriate function depending on the bitmap format of the current mode, i.e. there will be gfx_planar4_rect(), gfx_linear8_rect() and gfx_true24_rect(). Each of these functions implements the graphics operation in the most efficient way for the particular bitmap format. How would the above work with a bitblit function, exactly? > > > Why not have the platform set a suitable graphics mode? > > > In other words: rather than have the end-user code > > > determine a mode, which they can't do reliably, why > > > not have the mode be set for the end-user code. > > > > So you mean that "vmode" wouldn't take any arguments > > at all? > > Correct. > > > That would be possible. But then there will be other > > problems. For example, lets say that the i386 loader > > decides to use 640x480 @4bit, and the sparc64 loader > > decides that 1152x900 @8bit is "best". > > > > The Forth code clearly needs a way to query the resolution > > and bit depth that was set, so it can chose an appropriate > > background image. It might also have to chose a different > > font. > > Yes, that's generally the difficulty with graphics. > > > So the bottom line is that the Forth code cannot easily > > be abstracted from the hardware anyway. > > Well, it cannot be abstracted from the graphics settings, > but it is abstracted from the hardware. True. I agree. What I meant to say was this: The hardware dictates which graphics settings are available. So the Forth code depends on the hardware indirectly. But of course it shouldn't have to know anything about the hardware itself. > > There's also a problem when VESA support is added: It's > > not possible to reliable detect what resolutions the > > attached monitor supports, so by default we must use > > 640x480 anyway, even if VESA support is present and the > > hardware can do 16
OT: Stream structures in bzlib and zlib
Hey all! I'm currently working on a project using zlib and bzlib, and I'm currently slightly stomped by the fact that both define the input buffer in their stream structure as non-const. Generally, I'd assume that the input buffer is never changed (by any of the compression/decompression functions), and that it should thus be defined as a const pointer. My wrappers for them assume the same, of course. I've read the zlib manual, and there is some obscure function which uses the input buffer as temporary storage (restoring it on exit), but at least for the code paths I'm taking (the standard deflate/inflate), I'm pretty confident after skimming through the sources that they don't modify the input buffer and don't call into the function that does modify it (and thus a const_cast<> to set it up is perfectly okay). For bzlib, I'm less sure, as the sources are somewhat convoluted, and I probably didn't find all references to the input buffer in the code paths I checked. Before I go and test whether bzlib modifies the input buffer for temporaries (by simply passing it data in a RO segment and checking whether I get a SIGSEGV), is there anyone out there who's hit the same "problem" before and might shed some more insight whether I'll have to copy the data before setting it up in a stream structure as input? Thanks for any reply! -- Heiko Wundram Product & Application Development ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /boot/loader graphics support & extensibility
On Wed, Feb 20, 2008 at 01:44:42PM -0800, Marcel Moolenaar wrote: >control over everything. On top of that, we can't use any >code in the loader from the kernel, so whatever support we >add, we need to add to the kernel too. We can't re-use the same executable bytes but, with care, we should be able to reuse some of the source code. > At least, I think >it's lame to support fancy graphics in the loader and then >not support at least the same in the kernel. If you raise >the bar for the loader, you also have to raise it for the >kernel. How else would the kernel be able to use the console? We already have splash(4) and can support a character-mode interface to a graphics-mode adapter. IMHO, the major reason for having graphics support in the kernel is KGI/GGI - which offers the possibility of being able to use DDB from X. >So, the question is: how important is it for the user to >be able to tweak it all. For GGI, quite important because the kernel is defining the X resolution. Whether that needs to be the same as the resolution used by the boot loader is a different question. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpNWMAU4KDJs.pgp Description: PGP signature
