Re: Can I take a snapshot of the current stack for every thread in some process from outside?
Gdb. Thread apply all bt. Thanks, Max On Mar 2, 2012, at 4:49 PM, Yuri y...@rawbw.com wrote: I have the multithreaded process, each thread has some stack state at each point of time. For example during the timer tick when processes are switched? Is there a way to take a snapshot without disrupting a process? I was thinking gdb, but it requires the process to exit the system call to attach (?). DTrace is only activated particular sensors are crossed. So is there such a tool/command? Yuri ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: kbdcontrol: how to get us.iso on ukbd en.iso on atkbd ?
On Mon, Mar 8, 2010 at 9:02 AM, Julian H. Stacey j...@berklix.com wrote: Hi hackers@ Am I missing something obvious, or is a bit more needed in man kbdcontrol ? possibly the later :) What kbdcontrol[s] set an external USB keyboard (only) to eg American (or German etc), while leaving internal in English ? well, it may or may not work, depending on whether you want or don't want to use both keyboards at the same time [...] su kbdcontrol -k /dev/ukbd0 -l de.iso cannot open /dev/ukbd0: Device busy setting keymap: Inappropriate ioctl for device kbdcontrol -k /dev/ukbd0 -l de.iso /dev/console cannot open /dev/ukbd0: Device busy kbdcontrol -A /dev/ukbd0 -k /dev/kbdmux0 unable to obtain keyboard information: Inappropriate ioctl for device cannot open /dev/kbdmux0: Device busy kbdcontrol -A /dev/kbdmux0 -k /dev/ukbd0 unable to obtain keyboard information: Inappropriate ioctl for device cannot open /dev/ukbd0: Device busy kbdcontrol -K /dev/console kbd1 kbdmux0, type:AT 101/102 (2) kbdcontrol -a ukbd1 -l uk.iso /dev/console kbd1 kbdmux0, type:AT 101/102 (2) kbdcontrol: unable to (un)mux the keyboard: Invalid argument well, you should be using keyboard name (not keyboard device node name) in attach/detach, i.e. something like % kbdcontrol -A ukbd0 /dev/ttyv0 to detach ukbd0 from kbdmux. as you have realized, you can not do anything to a keyboard if kbdmux has control over it. so, you need to detach keyboard first. because kbdmux is essentially master keyboard if you set keyboard map on kbdmux, it will set the same keyboard map on all the slave keyboards. you might want to try - detach keyboard from kbdmux - set map on detached keyboard - reattach keyboard to kbdmux kbdmux does not set map on KBADDKBD ioctl(), so, in theory, it *might* work. also, please keep in mind that kbdmux will always set slave keyboard into K_RAW mode. thanks, max ___ 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: write-only variables in src/sys/ - possible bugs
On Mon, Feb 2, 2009 at 11:42 AM, Christoph Mallon christoph.mal...@gmx.de wrote: Hi, I compiled a list of all local variables in src/sys/ (r188000), which are only written to, but never read. This is more than the GCC warning, which only complains about variables, which are only declared (and maybe initialised) and not used otherwise. In contrast this list contains variables with the following usage pattern: int w = 42; // GCC warns about this ... int x; // ... but not this x = 23; x++; return 0; The list contains about 700 entries. About three dozen concern variables named 'error'. Here's one *example* from the list: sys/dev/kbdmux/kbdmux.c:1304 In the function kbdmux_modevent() the variable 'error' is assigned values eight times, but at the end of the function there is just a return 0; and the variable is never read. Probably the value should be returned. fixed. thanks for reporting! thanks, max ___ 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
converting strings from utf8
Hello, can i use wcstombs(3) to convert a string presented in utf8 into current locale? basically i'm looking for something like iconv from ports but included into base system. in other words, would something like this work? char *locale, dst[256]; size_t len; locale = setlocale(LC_CTYPE, ); if (locale == NULL) /* bail */ len = wcstombs(dst, (wchar_t *) src, sizeof(dst)); if (len 0) /* bail */ printf(%*.*s\n, len, len, dst); thanks, max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/127446: [patch] fix race in sys/dev/kbdmux/kbdmux.c
On 9/17/08, Eygene Ryabinkin [EMAIL PROTECTED] wrote: Maxim, good day. Cc'ing this discuission to hackers@ -- I was just going to write the separate letter on this topic to the list. Wed, Sep 17, 2008 at 09:56:14AM -0700, Maksim Yevmenkin wrote: have you tried to simply set KBDMUX_LOCK/UNLOCK() to mtx_lock/unlock(Giant) ? Since kbdmux callout is initialized as non-MPSAFE, this will result in double locking the Giant (at least I see it from the code). I am not sure that this is very good -- had not yet verified that Giant is recursive. yes, giant is recursive. i think it should be fine for now (and yes, i agree, its not very clean) Can try it tomorrow. thanks Since you had written the code and #if 0'ed the locking part, may I ask, why? Are there any known issues or it was just not very good to introduce locking at that time (rev. 1.1, 3 years ago)? because i did not want to touch every single keyboard driver, keyboard subsystem and syscons :) back then. since kbdmux is pretty much keyboard driver it was easier to leave it under giant locking. thanks, max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: temporary freezes when pressing capslock / numlock
On 5/26/08, Rick C. Petty [EMAIL PROTECTED] wrote: On Mon, May 26, 2008 at 10:11:09PM -0700, Jeremy Chadwick wrote: Being that the issue is on your wiki page, does that mean this problem will be fixed some day? Hopefully. :-) I'd like to point fingers at kbdmux being the responsible piece, but the USB stack has a history of being flakey in many regards, hence my reluctance. Agreed. I was never able to pinpoint it myself, but it certainly didn't show up before kbdmux. 1) what keyboards are used? usb only, ps2 only or mix? 2) what mice are used? usb only, ps2 only or mix? if ps2 devices (i.e. keyboard and mouse) are not used at all, does disabling atkbd(4) and/or psm(4) help? thanks, max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: temporary freezes when pressing capslock / numlock
On 5/27/08, Rick C. Petty [EMAIL PROTECTED] wrote: On Tue, May 27, 2008 at 10:34:47AM -0700, Maksim Yevmenkin wrote: Agreed. I was never able to pinpoint it myself, but it certainly didn't show up before kbdmux. 1) what keyboards are used? usb only, ps2 only or mix? 2) what mice are used? usb only, ps2 only or mix? if ps2 devices (i.e. keyboard and mouse) are not used at all, does disabling atkbd(4) and/or psm(4) help? I think I stated this in my original thread but let me restate. I've only noticed the problem when both usbkbd and atkbd are both enabled (as in the GENERIC kernel) and a USB keyboard (only) is attached. Once I plug in the atkbd, the problem goes away. The problem also does not exist if just the atkbd is plugged in with no USB keyboard. right, which (to me) seems to indicate that something is going wrong when kbdmux is trying to work on two keyboards (i.e. ukbd and atkbd) and one of them (i.e. atkbd) is not present. the problem, as i see it, is that atkbd keyboard is always present even if no physical ps2 keyboard is connected to the ps2 port. i understand that people are doing this in order to be able to hot plug ps2 keyboard (which is a bad idea as ps2 port was never designed to be hot pluggable, imo). now, kbdmux simply switches all slave keyboards into raw mode and pretends to have one keyboard with lots of duplicated keys. it also tries to preserve consistent state on all slave keyboards. so, for example, when num/scroll/capslock etc. key is pressed, ioctl is called to light up corresponding led on the keyboard. this ioctl calls driver specific routine which will talk to the hardware. because kbdmux tries to keep consistent state, it will call this ioctl for every slave keyboard. i suspect that because physical ps2 keyboard is not actually present, the atkbd driver will have to timeout while talking to non-present hardware. obviously the things work without kbdmux because without kbdmux it is not possible to have a keyboard without physical keyboard present. well, technically it is possible with atkbd, but then one could not press any keys to trigger atkbd driver to talk back to the non-present hardware. i suppose it is possible to write a simple program that uses console ioctl to flash keyboard leds and try to run it on a machine without kbdmux and no physical keyboard attached to the ps2 port to see if this triggers the same problem. so, as a suggestion, please try to specify 0x1 flag to atkbd, i.e. from atkbd(4) Driver Flags The atkbd driver accepts the following driver flags. They can be set either in /boot/device.hints, or else from within the boot loader (see loader(8)). bit 0 (FAIL_IF_NO_KBD) By default the atkbd driver will install even if a keyboard is not actually connected to the system. This option prevents the driver from being installed in this situation. ... and see if this helps. you wont be able to hot plug ps2 keyboards, but i suspect you probably can live without it. I haven't noticed a problem with the mice, but I've not used a PS/2 mouse in almost a decade. I have noticed a problem which has hit me rarely on a 6.x system; perhaps because the problem is not easily reproducable have I never seen it in 7.x. Basically I've seen the kernel get stuck and the only way to unstick it was to move the USB mouse. Moving the mouse allowed the interrupt to trigger and things would happen elsewhere in the kernel, but as soon as I stopped moving the mouse everything else stopped (ata reads/writes, graphics updates, etc.). Unplugging the mouse was a bad idea because the plugin event never triggered. I've only witnessed this on post-kbdmux systems but since it wasn't reproducable in any reliable fashion, I couldn't pin the problem down. well, i'm not sure it is the same problem, but if you have a way to reproduce it reliably and believe that it is a kbdmux related problem please let me know. thanks, max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: temporary freezes when pressing capslock / numlock
On 5/27/08, Rick C. Petty [EMAIL PROTECTED] wrote: On Tue, May 27, 2008 at 01:32:10PM -0700, Maksim Yevmenkin wrote: [...] i suspect that because physical ps2 keyboard is not actually present, the atkbd driver will have to timeout while talking to non-present hardware. Sure, but this timeout shouldn't be ~0.4 seconds. I believe the spec says the maximum wait period to tell if the device is nonresponsive is around or less than 20ms. Certainly, blocking the entire kernel for the timeout is a bad thing, especially since the driver should make full use of the asynchronous onboard keyboard controller. well, i just took a brief look at atkbd(4). specifically one function - wait_while_controller_busy(). this function polls status every KBDC_DELAYTIME (20) usec with retry count of 5000. so, just this function alone can give up to 100 msec delay. keep in mind that wait_while_controller_busy() is apparently called every time driver need to talk to the hardware. i can see how we could delay kernel for 400 msec or even more. so, as a suggestion, please try to specify 0x1 flag to atkbd, i.e. from atkbd(4) ... and see if this helps. you wont be able to hot plug ps2 keyboards, but i suspect you probably can live without it. I'm almost certain this will help, but I believe this shouldn't be the answer to this problem. There's no reason atkbdc(4) should block the entire kernel for any appreciable amount of time. agree. all i was trying to say is that kbdmux is only as good as underlying low level keyboard drivers. if a low level keyboard driver uses completely synchronous approach to poll the hardware, there is not much kbdmux can do about it. thanks, max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: temporary freezes when pressing capslock / numlock
On 5/27/08, Rick C. Petty [EMAIL PROTECTED] wrote: On Tue, May 27, 2008 at 02:28:26PM -0700, Maksim Yevmenkin wrote: well, i just took a brief look at atkbd(4). specifically one function - wait_while_controller_busy(). this function polls status every KBDC_DELAYTIME (20) usec with retry count of 5000. so, just this function alone can give up to 100 msec delay. keep in mind that wait_while_controller_busy() is apparently called every time driver need to talk to the hardware. i can see how we could delay kernel for 400 msec or even more. I'm not sure why we retry 5000 times. 100ms seems like a long time to block the entire kernel. Is there any reason we can't spawn a kernel thread to deal with the waits? I recommend that we also reduce the timeouts to at most twice what the spec states. all great ideas. please send in the patches and i will be happy to review and commit them for you. How come this doesn't happen when other keys are pressed? Just when the console is flipped. Perhaps because it tries to set the LEDs first? like i said, i suspect delay happens only when driver needs to send command to the keyboard. that is what happens when you press num/scroll/capslock. thanks, max -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: in-kernel tcp server
On 6/20/07, Julian Elischer [EMAIL PROTECTED] wrote: Nicolas Cormier wrote: On 6/20/07, John Polstra [EMAIL PROTECTED] wrote: Using ng_ksocket is almost the same as using the so* functions, since the ksocket methods call the so* functions. But by using netgraph, you get a nice management interface, too. For my application, I found that going through the socket layer (the so* functions and/or ng_ksocket) hurt performance too much. That's why I ended up bypassing them. Thanks for this precision. I would actually like to address the performance issues. is there any chance the oldest version (4.x based) might be released, or at least it would be nice to get the code snippet that attaches to eh ng_ksocket and reads and writes the stream.. I could make a TCP ECHO node that way and use it for tracking down the bottlenecks I'm not too interested in the actual webserver itself. he can take a look at bluetooth rfcomm sockets that are implemented on top of l2cap socket and feed into netgraph :) not exactly an in-kernel tcp server, but might give some ideas. thanks, max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: enable/disable in kbd drivers
On 3/29/07, Timothy Bourke [EMAIL PROTECTED] wrote: [...] Does the attached patch seem reasonable? It would fix my immediate problem. sorry for the delay. i'm not sure about this patch. basically, i do not think that keyboard should be disabled if it is released from kbdmux. it is perfectly fine, imo, to have two (or more) active keyboards attached to the system as long as only one of them is primary. it is possible to use /dev/kbdX interface to talk to non-primary keyboard(s) directly. It seems that, for the extant drivers: * enable only increments kb_active, * disable only decrements kb_active. well, yes, if all kbdmux did was call KBD_ACTIVATE/_DEACTIVATE directly, i would not have any problem with it. however, kbdmux calls enable() method and other drivers (such as the one you wrote) may do other things in enable/disable() methods. perhaps the right thing to do to is to have kbdmux check is keyboard is enabled and if not - call enable()? thanks, max With the printf suggested above, one can see that repeating the commands: kbdcontrol -A usb0 /dev/console kbdcontrol -a usb0 /dev/console continually increases kb_active. Even with the patch, detaching any of the current kbd drivers will not deactivate them (reduce kb_active to zero) because they all call enable (increment kb_active) when initialized. Which answers one of the other questions. Alternative (not serious) suggestion: since the disable hook seems never to be called, it might as well be removed from the keyboard_switch... Tim. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: enable/disable in kbd drivers
On 3/24/07, Timothy Bourke [EMAIL PROTECTED] wrote: I have almost finished a ppbus-based driver for Super Nintendo controllers. It presents itself as a keyboard to the operating system. I wanted to start and stop the polling thread via, respectively, the kbd_enable_t and kbd_disable_t hooks, but these do not seem to be called properly. Hence this post. The enable and disable functions are identical across the keyboard drivers (atkbd, ukbd, vkbd, kbdmux). Enable calls the KBD_ACTIVATE macro which increments the kb_active count. Disable calls the KBD_DEACTIVATE macro which decrements the kb_active count. It seems reasonable to assume that the two functions should be called in pairs. However, enable is called too many times and disable is never called. In the kbdmux_ioctl routine: KBADDKBD: enable is called via the KBDMUX_ENABLE macro. KBRELKBD: does NOT call disable Taking dev/usb/ukbd.c as an example, the effect can be seen by adding this line to the ukbd_enable function (after the call to KBD_ACTIVATE): printf(ukbd_enable: %d\n, KBD_IS_ACTIVE(kbd)); And similarly for ukbd_disable and then running dmesg or kbdcontrol. Additionally, each kbd driver calls its own enable function when attached. For example, in USB_ATTACH(ukbd): (*sw-enable)(kbd); This would appear to be unnecessary for keyboards connected via kbdmux. I am less certain about those connected directly, but the syscons sccngetch routine does seems to call enable and disable. Perhaps it should also call enable when it first starts? Does the attached patch seem reasonable? It would fix my immediate problem. sorry for the delay. i'm not sure about this patch. basically, i do not think that keyboard should be disabled if it is released from kbdmux. it is perfectly fine, imo, to have two (or more) active keyboards attached to the system as long as only one of them is primary. it is possible to use /dev/kbdX interface to talk to non-primary keyboard(s) directly. thanks, max I could write a patch to remove the calls to enable in the driver init routines but tI don't really understand how syscons works. Tim. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to Use ddb(4)?
Maxime Henrion wrote: Dag-Erling Sm?rgrav wrote: Maksim Yevmenkin [EMAIL PROTECTED] writes: so far i only got one (successful) report. would people please give it a try to see if work, so i can commit it. Please commit it. I don't see how it can do any harm. Yes please; I'd like to see this patch in HEAD as soon as possible so that we can have as much coverage as possible since this is the kind of fix that will be very desirable to MFC for 6.2-RELEASE. patch was committed to head yesterday. BTW, does your patch also fix similar problems with kbdmux(4) and the geli mountroot prompt? yes, it should. please let me know if you still have this kind of problems with kbdmux(4) and atkbd(4) thanks, max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to Use ddb(4)?
Maxime Henrion wrote: maksim yevmenkin wrote: Maxime Henrion wrote: Dag-Erling Sm?rgrav wrote: Maksim Yevmenkin [EMAIL PROTECTED] writes: so far i only got one (successful) report. would people please give it a try to see if work, so i can commit it. Please commit it. I don't see how it can do any harm. Yes please; I'd like to see this patch in HEAD as soon as possible so that we can have as much coverage as possible since this is the kind of fix that will be very desirable to MFC for 6.2-RELEASE. patch was committed to head yesterday. Yeah, I just saw it, I was quite behind with my mail. Thanks! BTW, does your patch also fix similar problems with kbdmux(4) and the geli mountroot prompt? yes, it should. please let me know if you still have this kind of problems with kbdmux(4) and atkbd(4) Great. I haven't had the time to look at the patch yet, but can you foresee any problem with MFC'ing it or would you consider it safe? i will mfc it in one week (just like the commit comment says). i can mfc it earlier providing that enough people try it and confirm that it fixes the problem. there should be no problem with mfc'ing it, imo. the patch is a minor hack and makes kbdmux(4) explicitly poll slave keyboards in polled mode only. thanks, max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to Use ddb(4)?
Dag-Erling Smørgrav wrote: Intron [EMAIL PROTECTED] writes: Dag-Erling [iso-8859-1] Smo/rgrav wrote: Intron [EMAIL PROTECTED] writes: When kernel panics, the prompt db will appear. But at this time I cannot control my computer with keyboard any longer. What's wrong with me? I don't know what's wrong with you, but as regards your computer: disable kbdmux and use a PS/2 keyboard. I've been comforted by you that there's nothing wrong with me. Glad to help :) Well, FreeBSD Developers' Handbook needs to be updated now. No, kbdmux needs to be fixed so it works in DDB. actually, atkbd(4) needs to be fixed to support polled mode :) however, this kbdmux(4) hack will, hopefully, make it work for everyone. http://lists.freebsd.org/pipermail/freebsd-current/2006-July/064727.html thanks, max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to Use ddb(4)?
Dag-Erling Smørgrav wrote: maksim yevmenkin [EMAIL PROTECTED] writes: Dag-Erling Smørgrav [EMAIL PROTECTED] writes: No, kbdmux needs to be fixed so it works in DDB. actually, atkbd(4) needs to be fixed to support polled mode :) It used to work fine before kbdmux(4) came along... because it makes certain assumptions about console (i.e. syscons(4)) driver. anyway, the link i posted in previous email contains a patch that should fix problems with kbdmux(4) and atkbd(4) not working in ddb(4), mid-boot (rootfs prompt, geli prompt, etc). so far i only got one (successful) report. would people please give it a try to see if work, so i can commit it. thanks, max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to Use ddb(4)?
Hans Petter Selasky wrote: On Thursday 27 July 2006 20:40, Dag-Erling Smørgrav wrote: maksim yevmenkin [EMAIL PROTECTED] writes: Dag-Erling Smørgrav [EMAIL PROTECTED] writes: No, kbdmux needs to be fixed so it works in DDB. actually, atkbd(4) needs to be fixed to support polled mode :) It used to work fine before kbdmux(4) came along... Just a comment: Don't forget to lock Giant before calling anything in the keyboard layer. That means DDB must lock Giant, else at least my new USB keyboard driver will panic, saying Giant is not owned. The old USB keyboard driver did not care about this. well, there is more work to it, imo. we will have to address this when new usb sub-system comes into the three. thanks, max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] does ukbd delay break scan codes?
Norbert, yes I too looked at ukbd code and found the same. I already put a patch on the bug list yesterday. good. does it fix your problem, i.e. keyboard freeze? if it does then i can commit it for you. In the mean time I compared the ukbd code to that of NetBSD and OpenBSD. Their code is quite different. I expect that the DragenFlyBSD guys may have the same problem, but did not find their cvs web site so far. yes, the code is different, but the logic should be the same. thanks, max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: does ukbd delay break scan codes?
Norbert, [...] I still do not know where it comes from, but what I found so far is, that the usb keyboard (or ukbd driver) seems to delay the break codes for keys with prefix E0 (which may or may not have anything to do with my problem). E.g., I press Keypad-Enter and see E0 1C E0 ^prefix ^make code ^prefix and nothing else. As soon as I press e.g. Enter (any key works) I see 9C 1C 9C ^break code ^make code ^delayed break code. Does anyone have an idea where that may come from? i see this to on week old -current. if ukbd(4) delays break code then this might explain state synchronization problem with kbdmux(4). i guess we should start digging into ukbd(4), starting with ukbd_interrupt() to see why this happening. Could it be a possible bug in ukbd's conversion code? could be (BTW: I compared ukbd.c of RELENG-4 against RELENG-6. There are no significant differences) have you tried to look at other bsd's (i.e. netbsd for example)? My usb keyboard is a Cherry RS6000. i do not think this has anything to do with the keyboard. i have ps/2-to-usb converter and use ps/2 keyboard with it, and, it has exactly the same problem. thanks, max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: does ukbd delay break scan codes?
Maksim Yevmenkin wrote: Norbert, [...] I still do not know where it comes from, but what I found so far is, that the usb keyboard (or ukbd driver) seems to delay the break codes for keys with prefix E0 (which may or may not have anything to do with my problem). E.g., I press Keypad-Enter and see E0 1C E0 ^prefix ^make code ^prefix and nothing else. As soon as I press e.g. Enter (any key works) I see 9C 1C 9C ^break code ^make code ^delayed break code. Does anyone have an idea where that may come from? i see this to on week old -current. if ukbd(4) delays break code then this might explain state synchronization problem with kbdmux(4). i guess we should start digging into ukbd(4), starting with ukbd_interrupt() to see why this happening. just by looking at the code, i think, that ukbd_check_char() should also return true if ks_buffered_char[0] != 0, i.e. try the following untested patch --- ukbd.c.orig Thu Feb 23 14:24:21 2006 +++ ukbd.c Thu Feb 23 14:25:47 2006 @@ -1145,9 +1145,7 @@ state = (ukbd_state_t *)kbd-kb_data; if (!(state-ks_flags COMPOSE) (state-ks_composed_char 0)) return TRUE; - if (state-ks_inputs 0) - return TRUE; - return FALSE; + return ukbd_check(kbd); } /* some useful control functions */ === i will try this as soon as my buildworld/buildkernel completes. thanks, max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] does ukbd delay break scan codes?
Maksim Yevmenkin wrote: [...] I still do not know where it comes from, but what I found so far is, that the usb keyboard (or ukbd driver) seems to delay the break codes for keys with prefix E0 (which may or may not have anything to do with my problem). E.g., I press Keypad-Enter and see E0 1C E0 ^prefix ^make code ^prefix and nothing else. As soon as I press e.g. Enter (any key works) I see 9C 1C 9C ^break code ^make code ^delayed break code. Does anyone have an idea where that may come from? i see this to on week old -current. if ukbd(4) delays break code then this might explain state synchronization problem with kbdmux(4). i guess we should start digging into ukbd(4), starting with ukbd_interrupt() to see why this happening. just by looking at the code, i think, that ukbd_check_char() should also return true if ks_buffered_char[0] != 0, i.e. try the following untested patch i have tested the attached patch. it works for me. with this patch usb keyboard return Feb 23 17:30:54 beetle kernel: e0 1c Feb 23 17:30:54 beetle kernel: e0 9c when i press gray enter key and ps/2 keyboard return Feb 23 17:31:41 beetle kernel: e0 Feb 23 17:31:41 beetle kernel: 1c Feb 23 17:31:41 beetle kernel: e0 Feb 23 17:31:41 beetle kernel: 9c also i tried to freeze my keyboards by pressing ctrl+f1 but i can not reproduce it here. thanks, max --- ukbd.c.orig Wed Mar 30 00:32:41 2005 +++ ukbd.c Thu Feb 23 17:18:37 2006 @@ -1145,9 +1145,7 @@ state = (ukbd_state_t *)kbd-kb_data; if (!(state-ks_flags COMPOSE) (state-ks_composed_char 0)) return TRUE; - if (state-ks_inputs 0) - return TRUE; - return FALSE; + return ukbd_check(kbd); } /* some useful control functions */ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bus error in strsep
Stefan,
int main(int argc, char* argv[])
{
char *c = whats:your:name:buddy?;
that is not read only copy. you can not write
into it. replace it with
char *c = strdup(whats:your:name:buddy?);
(void*)mystrsep(c, :);
}
and it should work.
thanks,
max
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bus error in strsep
Maksim Yevmenkin wrote:
Stefan,
int main(int argc, char* argv[])
{
char *c = whats:your:name:buddy?;
that is not read only copy. you can not write into it.
replace it with
made type. that should read that is read only copy :)
char *c = strdup(whats:your:name:buddy?);
(void*)mystrsep(c, :);
}
and it should work.
thanks,
max
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bus error in strsep
int main(int argc, char* argv[])
{
char *c = whats:your:name:buddy?;
that is not read only copy. you can not write
into it. replace it with
char *c = strdup(whats:your:name:buddy?);
Or the following:
char c[] = whats:your:name:buddy?;
which doesn't require a free() operation when you're done with c[].
actually it still will crash :)
beetle% cat 5.c
#include string.h
int
main(int argc, char* argv[])
{
char c[] = whats:your:name:buddy?;
strsep((char **) c, :);
return (0);
}
beetle% gcc -Wall -ggdb 5.c
beetle% ./a.out
Segmentation fault (core dumped)
so something like this
#include string.h
int
main(int argc, char* argv[])
{
char c[] = whats:your:name:buddy?, *s = c;
strsep((char **) s, :);
return (0);
}
will work too.
max
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: using vkbd device
Hello Norbert, I did some more testing with kbdmux. 1. I wait for the screen saver becoming active. 2. I press the control key. 3. All keys, I press after that, come as control keys, e.g. I press 'j' or 'J' and see a linefeed, I press 'I' and see a tab. 4. I wait a second time for the screen saver. 5. I press control. 6. The keys are ok now. Does syscons eat up the key but sets the state in kbdmux? hmmm... i can not reproduce it here (on -current). could you please try the latest code. i have included some of your patches and did a compile only test on 4.x system (freefall.freebsd.org). http://www.geocities.com/m_evmenkin/kbdmux-3.tar.gz it also fixes (hopefully) issues with state synchronization (lights, etc.). thanks, max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic in usb0; was: RE: using vkbd device
Norbert, The ukbd-specific detaching only works, because I implemented something in ukbd.c, that Hans Petter Selasky [EMAIL PROTECTED] suggested in thread usbd.conf: detach ukbd. (See the patch files, I posted there) When the kernel panics, it does this in usb0 kernel thread. I figured out that this is only related to connecting/disconnecting the usb keyboard. It panics without kbdmux loaded and it panics with unmodified ukbd.c. So I'll have to try to remote debug it, as my embedded device has no swap space at all and so no core dump device (256MB flash/256 MD dram). I am observing spurious crashes in usb0 under FreeBSD 4.11. Kernel configuration/hardware: HZ=400, NO_SWAPPING, DEVICE_POLLING (with kern.polling.user_frac=90), fxp ethernet, 6x sio, ohci, Pentium MMX 166 MHz could you try to compile kernel with debugging information? not sure if it will fit into ram. When quickly connecting/disconnecting i guess you mean here unplug the keyboard and then immediately plug it back, right? a usb keyboard, after some time I have a panic in process 3 (usb0), either at usbd_ar_pipe+0x7 (when detaching) or at usbd_get_interface_descriptor+0x6 (when attaching). Stack traces are: (a) usbd_ar_pipe+0x7 usbd_ar_pipe(0,...) usbd_abort_pipe(0,...) ukbd_enable_intr() ukbd_term() ukbd_detach() DEVICE_DETACH() device_detach() device_delete_child() usb_discommect_port() uhub_explore() usb_discover() usb_event_thread() can you tell what value pipe handle has? i suspect its NULL (b) usbd_get_interface_descriptor+0x6 usbd_get_interface_descriptor(0) ukbd_attach(c0bf3b80) DEVICE_ATTACH() device_probe_and_attach() usbd_probe_and_attach() usbd_new_device() uhub_explore() usb_discover() usb_event_thread() can you tell what value iface handle has? i suspect its NULL can you please compile the kernel with DIAGNOSTIC and check for messages from usb system? In situation(a), ipl is at bio, ks_intr_pipe is NULL when calling usbd_abort_pipe(). thats ok. splusb is defined as splbio In situation (b), ipl is at none, USB_ATTACH_START() in USB_ATTACK(ukbd) in ukbd.c seems to make problems. not sure about this one The above stack traces are from ddb. Booting the kernel with -gd and using gdb -k didn't give more information. I almost always get an unusable empty stack trace and different crash addresses. too bad :( It seems like 'usbd_setup_pipe: failed to start endpoint, IOERROR' always comes before the crash and ipl is mostly at bio, never at usb. what is your usb controller? uhci/ohci? what chip? When I'm doing these tests, I have an ssh console connected through fxp0 where I run usbd -dv. Any idea? please compile kernel with DIAGNOSTIC and USB_DEBUG. then try to adjust various debug knobs with sysctl(8) to get debug traces. at this point it looks like a race condition of some sort (to me). thanks, max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: using vkbd device
Hi Norbert, you also might want to look at experimental keyboard mux drivers. it is based on vkbd(4) and uses the idea of one super-keyboard that consumes scancodes from other keyboards. there are still a few issues i need to fix, but, in general, it works. http://www.geocities.com/m_evmenkin/kbdmux-2.tar.gz I back-ported kbdmux to FreeBSD 4.11 (and stopped work on vkbd). It thanks for your work and patches! i will merge some of your changes into my version. this way it will be easier to maintain (that is if kbdmux(4) will be included in FreeBSD :-) seems to work, although I still have some stability issues with dynamically attaching/detaching a usb keyboard. For your reference I would you share with us what sort of issues you are having? feel free to move this into private email if you are not comfortable discussing it on public mailing list. have enclosed a patch file. Sorry for some diffs due to slightly different coding and debugging style. no problem. in one of your previous emails you have been concerned about possible keyboard interrupt miss (in vkbd(4)). kbdmux(4) have the same issue. is that something you just did not fix yet, or it is not a problem anymore? in my local tree a added an extra callout that goes 10 times a second and queues interrupt if needed. also i'm curious why do you use splhigh() instead of spltty()? is this an issue with usb? (not sure which spl level usb runs on in 4.x) thanks, max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usbd.conf: detach ukbd
Norbert, when running usbd (under FreeBSD 4.11) with -dv switches I can see that a usb keyboard correctly attaches as ukbd0, but detaches as fall-through USB device. can you please tell what is in your /etc/usbd.conf? Do I just have to live with that fact or can I change that anyhow? Is that a device/device-class specific problem? does something like device USB keyboard devname ukbd[0-9]+ attach foo detach bar work? note: please replace foo and bar with actual commands you want to be executed. thanks, max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: using vkbd device
Norbert, I am trying to use vkbd to multiplex an at keyboard and an usb keyboard into syscons. ok Vkbd's control device's write routine expects ints to queue to the slave device. correct As I understand, those ints map 1:1 to the chars I read from a keyboard device, right? yes, the ints should represent AT keyboard scancodes. So I open, for example, /dev/kbd0, set it to K_RAW, read chars from it and write them as ints to vkbd's control device, right? yes, it should work. keep in mind that vkbd(4) emulates only one keyboard and keeps only one state. that is if you feed scancodes from multiple sources into the same vkbd(4) then it will look like one huge keyboard with lots of duplicated keys. so you can press shift/ctrl/alt on one keyboard and actual key on another, but it still will look like you have presses the keys on the same keyboard. you also might want to look at experimental keyboard mux drivers. it is based on vkbd(4) and uses the idea of one super-keyboard that consumes scancodes from other keyboards. there are still a few issues i need to fix, but, in general, it works. http://www.geocities.com/m_evmenkin/kbdmux-2.tar.gz thanks, max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: synchronization question about /sys/dev/vkbd/vkbd.c
Norbert,
When looking at /sys/dev/vkbd/vkbd.c I found
one thing, that I do not understand.
There are three places, where a flag TASK is used:
1. in vkbd_dev_close():
while(state-ks_flag TASK) VKBD_SLEEP (...);
2. in vkbd_dev_write()
VKBD_LOCK ();
...
if (!(state-ks_flags TASK) task_enqueue(...))
state-ks_flags |= TASK;
...
VKBD_UNLOCK ();
3. in vkbd_dev_intr()
...
/* call intr */
...
VKBD_LOCK();
state-ks_flags = ~TASK;
wakeup(...);
VKBD_UNLOCK();
As I understand:
vkbd_dev_write() writes data into its queue
and wants vkbd_dev_intr() to process the queue.
vkbd_dev_intr() is a interrupt handler. the real keyboard would
generate interrupt when keys are pressed/released. vkbd(4) does not have
real keyboard. instead, as soon as vkbd_dev_write() puts scancodes into
the queue it schedules vkbd_dev_intr() task (to emulate keyboard
interrupt). the TASK flag is used to indicate the fact that intrrupt
is pending and vkbd(4) does not need to schedule one.
My question is:
Is it not possible, that vkbd_dev_intr() could be
interrupted at any position before the VKBD_LOCK()
and then vkbd_dev_write() called?
in theory it is possible.
If yes, how should vkbd_dev_write() know, that it should
call task_enqueue(), as TASK is still set?
well, i guess it is possible to miss interrupt in this case. also, the
scancodes are not lost, they will be processed on next write.
i suspect that the vkbd_dev_intr() should be interrupted exactly in between
(*kbdsw[kbd-kb_index]-intr)(kbd, NULL);
and
VKBD_LOCK(state);
this is because most/all of intr() keyboard methods have something like
while (check_char) {
read_char()
...
}
Why not always call task_enqueue() unconditionally here
and leave TASK only to synchronize the close call?
yes, that could be done. it is also possible to have a callout going few
times a second to check if there is a scancodes in the queue and
schedule vkbd_dev_intr(). funny that atkbd(4) and ukbd(4) have just this.
thanks,
max
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mutual exclusion in vkbd
Norbert, I am currently trying to backport vkbd to FreeBSD 4. ok Maksim Yevmenkin uses mtx_lock()/mtx_unlock() for protecting access to data structures under FreeBSD 5/6 between the device functions and the kernel thread. How should I best do this under FreeBSD 4? Would something like splhigh() work in that context? Or should I use lockmgr with LK_EXCLUSIVE/LK_RELEASE? Is there any (pseudo)process context inside a kernel task? spltty() is what you probably need to use. you could just adjust the following defines like #define VKBD_LOCK_DECL int #define VKBD_LOCK_INIT(s) /* noop */ #define VKBD_LOCK_DESTROY(s)/* noop */ #define VKBD_LOCK(s)(s)-ks_lock = spltty() #define VKBD_UNLOCK(s) splx((s)-ks_lock) #define VKBD_LOCK_ASSERT(s, w) #define VKBD_SLEEP(s, f, d, t) \ tsleep((s)-f, PCATCH | (PZERO + 1), d, t) and you should be done. its not really required to store interrupt mask in softc structure, but this way its less changes to the code. thanks, max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mutual exclusion in vkbd
Alexander Kabaev wrote: On Tue, May 31, 2005 at 09:41:18AM -0700, Maksim Yevmenkin wrote: Norbert, I am currently trying to backport vkbd to FreeBSD 4. ok Maksim Yevmenkin uses mtx_lock()/mtx_unlock() for protecting access to data structures under FreeBSD 5/6 between the device functions and the kernel thread. How should I best do this under FreeBSD 4? Would something like splhigh() work in that context? Or should I use lockmgr with LK_EXCLUSIVE/LK_RELEASE? Is there any (pseudo)process context inside a kernel task? spltty() is what you probably need to use. you could just adjust the following defines like #define VKBD_LOCK_DECL int #define VKBD_LOCK_INIT(s) /* noop */ #define VKBD_LOCK_DESTROY(s)/* noop */ #define VKBD_LOCK(s)(s)-ks_lock = spltty() #define VKBD_UNLOCK(s) splx((s)-ks_lock) #define VKBD_LOCK_ASSERT(s, w) #define VKBD_SLEEP(s, f, d, t) \ tsleep((s)-f, PCATCH | (PZERO + 1), d, t) The code above will probably crash the kernel in many spectacular and unpredictable ways. You will need to save interrupt flags locally to each VKBD_LOCK caller or they will end up restoring each other's flags. yes, you are correct. my bad :( thanks for catching this max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tricky USB device.
David, I've got an OnTrak ADU208. It's a USB device that has 8 relays and 8 ttl inputs. The documentation says it uses two interupt endpoints ... one input and one output. It seems to expect small text commands. ok Now... firstly, uhid is probing it as uhid0: uhid0: www.ontrak.net ADU208 USB Relay I/O Interface, rev 1.10/0.00, addr 4, iclass 3/0 ... I don't know if this is hindering me. The usbhid* commands aren't particularly helpful. The port udesc_dump seems only to work on ugen devices ... and ugen doesn't pop up for this device. how about getting usb hid descriptor, parsing and dumping it? check out libusbhid - man usbhid(3). it might be that all you need to do is to create hid report and send it to the device. libusbhid(3) will help you with that. I suppose I need to know how to supress uhid ... or to make ugen show up. It would also be nice to know how to generically poke the interupt enpoints... well comment out 'device uhid' from your kernel config and rebuilding the kernel should do the trick. max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tricky USB device.
David, ... I don't know if this is hindering me. The usbhid* commands aren't particularly helpful. The port udesc_dump seems only to work on ugen devices ... and ugen doesn't pop up for this device. Maksim how about getting usb hid descriptor, parsing and dumping it? Maksim check out libusbhid - man usbhid(3). it might be that all you Maksim need to do is to create hid report and send it to the Maksim device. libusbhid(3) will help you with that. Tried that. The usb_get_report_desc() returns NULL. This is not a complicated device --- it's not even technically a human interface device. fine, so i presume usbhidctl(1) does not work on the device too. why did they made look like usb hid device then? I suppose I need to know how to supress uhid ... or to make ugen show up. It would also be nice to know how to generically poke the interupt enpoints... Maksim well comment out 'device uhid' from your kernel config and Maksim rebuilding the kernel should do the trick. I wanted to try to avoid that since I use many USB devices, but it's a last resort kind-of-thing. well, for what i know ugen(4) will only claim the device if no other usb device driver claimed it. so if the uhid(4) claimed it than (i assume) usb interface class on the device is set to the appropriate value. The documentation for the device describes the interface as simply using the two interupt endpoints (read and write). another way is to hack /sys/dev/usd/uhid.c and specifically ignore (usb vendor id, usb product id) for the device in the MATCH routine. something like if (uaa-vendor == uaa-product == ) return (UMATCH_NONE); max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tricky USB device.
David, Bernd Then it really shouldn't have claimed to be one in the Bernd interface descriptor :( But the HID specification is more today Bernd than just _human_ interface. e.g. there are extensions for Bernd USV, ... [...] Bernd Has this device multiple interfaces? e.g. one HID and another Bernd as described. I often thought about getting ugen working at Bernd interface level too. Here's the output of udesc_dump on it. Right now, using the current version of libusb (not the version from ports), I can use usb_interrupt_write(dev, 1, MK255, 5, 0) to send data to it --- and the data is sent --- at least lights on the USB hub flash. If I replace '1' with anything else, it doesn't accept it. However, it doesn't seem to have opened the relays. hmm... why even use libusb? cant you just fd = open(/dev/ugen0.1, O_RDWR); and then write(fd, MK255, 5) and read(fd, ...);. note: here i assume ugen0 is the device. I'm also not entirely clear how/when to use usb_interrupt_read() ... as many of the commands listed in the manual return data, but usb_inerrupt_write() doesn't seem to allow for data to be returned, but following usb_interrupt_write(), the read will hang. i'd guess you have to keep read pipe open at all times. that is what fd = open(/dev/ugen0.1, O_RDWR); will do - it will open both read and write pipes (because of O_RDWR). then you just write(fd, ...); read(fd, ...); max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tricky USB device.
Bernd Walter wrote: On Fri, Apr 08, 2005 at 06:12:33PM -0400, David Gilbert wrote: Bernd Has this device multiple interfaces? e.g. one HID and another Bernd as described. I often thought about getting ugen working at Bernd interface level too. Here's the output of udesc_dump on it. Right now, using the current version of libusb (not the version from ports), I can use usb_interrupt_write(dev, 1, MK255, 5, 0) to send data to it --- and the data is sent --- at least lights on the USB hub flash. If I replace '1' with anything else, it doesn't accept it. However, it doesn't seem to have opened the relays. Yes - you must use 1 - there is only one out-endpoint. 0x81 is for receiving data and endpoint 0 is the mandandory control endpoint. Interrupt Endpoints are not variable in size. Both interrupt endpoints are 8 Bytes, so you must read and write exact 8 Bytes per transfer - 5 shouldn't work for USB compliant devices. hmmm... i was always confused about bMaxPacketSize. i was thinking that it limits the size of one usb transaction, and it could take several usb transactions to transfer one data packet. for example i have a bluetooth usb dongle that has Standard Endpoint Descriptor: bLength 7 bDescriptorType 05 bEndpointAddress 81 (in) bmAttributes 03 (Interruput) wMaxPacketSize 16 bInterval1 and i certanly can receive data packets from this endpoint that are more (and less) then 16 bytes in size. so, i would guess (and i might be wrong) that it is ok to send/receive data packets that are not equal to bMaxPacketSize in size. max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: netgraph TTY
Jerry Toung wrote: Hey Max, all I can say is thank you. That's a very nice tutorial. I am sure other people will benefit. so, did i get job at nasa? :) btw, i did miss one command (naming one2many node) while cut-and-paste'ing this from my screen, i.e. + mkpeer tee: one2many left2right many0 + connect tee: tee:left2right right2left many1 + name tee:left2right one2many + show one2many: thanks, max Take care my friend. Jerry On Wednesday 30 March 2005 05:22 pm, Maksim Yevmenkin wrote: Jerry, draw a picture :) it really helps :) for example right2left left2right \ / [ksocket] --- [tee] [hole] left right # ngctl + mkpeer hole hook hook -- create ng_hole node + name hook hole -- name ng_hole node + mkpeer hole: tee right right -- create ng_tee node and connect to hole + name hole:right tee -- name ng_tee node + mkpeer tee: ksocket left local/stream/0 -- create ksocket node and connect to tee + name tee:left ksocket -- name ksocket node + msg ksocket: bind local//tmp/foo -- bind ksocket + show tee: Name: tee Type: tee ID: 0011 Num hooks: 2 Local hook Peer name Peer typePeer ID Peer hook -- - ---- - leftksocket ksocket 0012 local/stream/0 right holehole 0010right + show ksocket: Name: ksocket Type: ksocket ID: 0012 Num hooks: 1 Local hook Peer name Peer typePeer ID Peer hook -- - ---- - local/stream/0 tee tee 0011left + show hole: Name: holeType: holeID: 0010 Num hooks: 2 Local hook Peer name Peer typePeer ID Peer hook -- - ---- - right tee tee 0011right hookngctl8529 socket 000fhook now connect nghook(8) to tee:left2right (or you could connect ng_tty node there), then connect to the unix socket at /tmp/foo and send something to the socket. you should see output. since we have ng_hole on the right then right2left will never get any data. if you need to capture traffic from from right2left then you will need to connect one2many node to both right2left (to one2many:many0) and right2left (to one2name:many1) and then connect your tty node to the one2many:one hook like so + mkpeer tee: one2many left2right many0 + connect tee: tee:left2right right2left many1 + show one2many: Name: one2manyType: one2manyID: 0014 Num hooks: 2 Local hook Peer name Peer typePeer ID Peer hook -- - ---- - many1 tee tee 0011 right2left many0 tee tee 0011 left2right + show tee: Name: tee Type: tee ID: 0011 Num hooks: 4 Local hook Peer name Peer typePeer ID Peer hook -- - ---- - right2left one2manyone2many 0014many1 left2right one2manyone2many 0014many0 leftksocket ksocket 0012 local/stream/0 right holehole 0010right hope this helps :) max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: netgraph TTY
Jerry,
draw a picture :) it really helps :) for example
right2left left2right
\ /
[ksocket] --- [tee] [hole]
left right
# ngctl
+ mkpeer hole hook hook -- create ng_hole node
+ name hook hole -- name ng_hole node
+ mkpeer hole: tee right right -- create ng_tee node and connect to hole
+ name hole:right tee -- name ng_tee node
+ mkpeer tee: ksocket left local/stream/0 -- create ksocket node and
connect to tee
+ name tee:left ksocket -- name ksocket node
+ msg ksocket: bind local//tmp/foo -- bind ksocket
+ show tee:
Name: tee Type: tee ID: 0011 Num hooks: 2
Local hook Peer name Peer typePeer ID Peer
hook
-- - ----
-
leftksocket ksocket 0012
local/stream/0
right holehole 0010right
+ show ksocket:
Name: ksocket Type: ksocket ID: 0012 Num hooks: 1
Local hook Peer name Peer typePeer ID Peer
hook
-- - ----
-
local/stream/0 tee tee 0011left
+ show hole:
Name: holeType: holeID: 0010 Num hooks: 2
Local hook Peer name Peer typePeer ID Peer
hook
-- - ----
-
right tee tee 0011right
hookngctl8529 socket 000fhook
now connect nghook(8) to tee:left2right (or you could connect ng_tty
node there), then connect to the unix socket at /tmp/foo and send
something to the socket. you should see output. since we have ng_hole on
the right then right2left will never get any data. if you need to
capture traffic from from right2left then you will need to connect
one2many node to both right2left (to one2many:many0) and
right2left (to one2name:many1) and then connect your tty node to the
one2many:one hook
like so
+ mkpeer tee: one2many left2right many0
+ connect tee: tee:left2right right2left many1
+ show one2many:
Name: one2manyType: one2manyID: 0014 Num hooks: 2
Local hook Peer name Peer typePeer ID Peer
hook
-- - ----
-
many1 tee tee 0011
right2left
many0 tee tee 0011
left2right
+ show tee:
Name: tee Type: tee ID: 0011 Num hooks: 4
Local hook Peer name Peer typePeer ID Peer
hook
-- - ----
-
right2left one2manyone2many 0014many1
left2right one2manyone2many 0014many0
leftksocket ksocket 0012
local/stream/0
right holehole 0010right
hope this helps :)
max
Jerry Toung wrote:
Good afternoon list,
I am still trying to build a simple netgraph using ng_tty. Ultimately I would
like to go from inet-tee-ng_tty(/dev/cuaa0).
Please advise what I am doing wrong as I still see an error message (see
bottom of email). Excuse me for the slighty long thread.
Here is my very simple line discipline code:
int d;
int ldisc;
ldisc = NETGRAPHDISC;
if ((d = open(/dev/cuaa0, O_RDWR)) == -1) {
perror(open);
} else {
printf(descripto # %d\n, d);
if ((ioctl(d, TIOCSETD, ldisc)) == -1) {
perror(ioctl);
}
}
printf(Netgraph TTY node initialized successfully\nPress any key to
destroy it);
getc(stdin);
close(d);
exit;
mrcrab# gcc -g netgraph.c -o test
mrcrab# ./test
descripto # 3
Netgraph TTY node initialized successfully
Press any key to destroy it
+ list
There are 2 total nodes:
Name: ngctl27022 Type: socket ID: 000a Num hooks: 0
Name: tty1Type: tty ID: 0008 Num hooks: 0
+ mpeer . tee myhook right
ngctl: mpeer: unknown command
+ mkpeer . tee myhook right
+ name .:myhook mytee
+ mkpeer mytee: tty left hook
ngctl: send msg: Operation not permitted
+
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [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: Network interface RUNNING and UP flags
Hello,
Here, I pushed that section of code up before the prior
mtx_unlock(tp-tap_mtx) above it, then removed the splimp/splx
calls. Is this what you were referring to (attached)? Also, I noticed
splx and splimp are called in a number of other places in this
driver, even under -CURRENT. You want those out too? The patch is a
patch on the original -CURRENT version of the driver and not a patch
to the previous patch I received.
ok, the tap_mtx lock is used to protect fields which belongs to the
struct tap_softc. the IFF_xxx flags are set in the if_flags field,
which belongs to the struct ifnet. note that other parts of the system
will access the same struct ifnet, and, thus separate lock is required
to protect all fields inside the struct ifnet. currently it is done
(or rather not done) with splimp(9)/splx(9) calls. i guess this will be
fixed some time in the future.
my original patch was not 100% correct. i have attached better (imo)
patch. please try it out, and, if there are no objections, i will commit it.
thanks,
max
--- if_tap.c.orig Fri Aug 6 15:02:06 2004
+++ if_tap.cMon Aug 9 13:57:48 2004
@@ -340,7 +340,8 @@
struct thread *td;
{
struct tap_softc*tp = NULL;
- int error;
+ struct ifnet*ifp = NULL;
+ int error, s;
if ((error = suser(td)) != 0)
return (error);
@@ -368,10 +369,15 @@
bcopy(tp-arpcom.ac_enaddr, tp-ether_addr, sizeof(tp-ether_addr));
tp-tap_pid = td-td_proc-p_pid;
tp-tap_flags |= TAP_OPEN;
+ ifp = tp-tap_if;
mtx_unlock(tp-tap_mtx);
- TAPDEBUG(%s is open. minor = %#x\n,
- tp-tap_if.if_xname, minor(dev));
+ s = splimp();
+ ifp-if_flags |= IFF_RUNNING;
+ ifp-if_flags = ~IFF_OACTIVE;
+ splx(s);
+
+ TAPDEBUG(%s is open. minor = %#x\n, ifp-if_xname, minor(dev));
return (0);
} /* tapopen */
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Network interface RUNNING and UP flags
2) Is there a way to set this interface flag without assigning an IPv4
address (or any address for that matter) first?
Mainly for number two, I would like to be able to run interfaces
bridged together without having to also give all of them addresses.
please try the attached (untested!) patch. it should set iff_running
flag on the interface as soon as the control device is opened.
max
--- if_tap.c.orig Fri Aug 6 15:02:06 2004
+++ if_tap.cFri Aug 6 15:04:14 2004
@@ -336,15 +336,15 @@
tapopen(dev, flag, mode, td)
struct cdev *dev;
int flag;
int mode;
struct thread *td;
{
struct tap_softc*tp = NULL;
- int error;
+ int error, s;
if ((error = suser(td)) != 0)
return (error);
if ((dev2unit(dev) CLONE_UNITMASK) TAPMAXUNIT)
return (ENXIO);
@@ -365,14 +365,19 @@
return (EBUSY);
}
bcopy(tp-arpcom.ac_enaddr, tp-ether_addr, sizeof(tp-ether_addr));
tp-tap_pid = td-td_proc-p_pid;
tp-tap_flags |= TAP_OPEN;
mtx_unlock(tp-tap_mtx);
+
+ s = splimp();
+ tp-tap_if.if_flags |= IFF_RUNNING;
+ tp-tap_if.if_flags = ~IFF_OACTIVE;
+ splx(s);
TAPDEBUG(%s is open. minor = %#x\n,
tp-tap_if.if_xname, minor(dev));
return (0);
} /* tapopen */
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
[PATCH] libusbhid(3)
Dear Hackers,
does anyone objects to the attached libusbhid(3) patch? unpatched library
gives me wrong HID page/usage values when i try to parse HID descriptor
from Microsoft Bluetooth keyboard. please see attached patched.txt and
unpatched.txt outputs.
thanks,
max
__
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.htmlIndex: parse.c
===
RCS file: /home/ncvs/src/lib/libusbhid/parse.c,v
retrieving revision 1.9
diff -u -r1.9 parse.c
--- parse.c 28 Jan 2004 00:05:22 - 1.9
+++ parse.c 10 Feb 2004 23:51:27 -
@@ -213,12 +213,11 @@
dval = 0;
break;
case 1:
- dval = (int8_t)*data++;
+ dval = *data++;
break;
case 2:
dval = *data++;
dval |= *data++ 8;
- dval = (int16_t)dval;
break;
case 4:
dval = *data++;
Index: usbhid.h
===
RCS file: /home/ncvs/src/lib/libusbhid/usbhid.h,v
retrieving revision 1.9
diff -u -r1.9 usbhid.h
--- usbhid.h9 Apr 2003 01:52:48 - 1.9
+++ usbhid.h10 Feb 2004 23:51:27 -
@@ -45,7 +45,7 @@
typedef struct hid_item {
/* Global */
- int _usage_page;
+ unsigned int _usage_page;
int logical_minimum;
int logical_maximum;
int physical_minimum;
Collection page=Generic_Desktop usage=Keyboard
Output id=1 size=1 count=1 page=LEDs usage=Num_Lock Variable, logical range 0..1
Output id=1 size=1 count=1 page=LEDs usage=Caps_Lock Variable, logical range 0..1
Output id=1 size=1 count=1 page=LEDs usage=Scroll_Lock Variable, logical range 0..1
Output id=1 size=1 count=1 page=LEDs usage=Generic_Indicator Variable, logical range
0..1
Output id=1 size=1 count=4 page=0x usage=0x Const, logical range 0..1
Input id=1 size=1 count=1 page=Keyboard usage=Keyboard_LeftControl Variable, logical
range 0..1
Input id=1 size=1 count=1 page=Keyboard usage=Keyboard_LeftShift Variable, logical
range 0..1
Input id=1 size=1 count=1 page=Keyboard usage=Keyboard_LeftAlt Variable, logical
range 0..1
Input id=1 size=1 count=1 page=Keyboard usage=Keyboard_Left_GUI Variable, logical
range 0..1
Input id=1 size=1 count=1 page=Keyboard usage=Keyboard_RightControl Variable,
logical range 0..1
Input id=1 size=1 count=1 page=Keyboard usage=Keyboard_RightShift Variable, logical
range 0..1
Input id=1 size=1 count=1 page=Keyboard usage=Keyboard_RightAlt Variable, logical
range 0..1
Input id=1 size=1 count=1 page=Keyboard usage=Keyboard_Right_GUI Variable, logical
range 0..1
Input id=1 size=8 count=1 page=0x usage=0x Const, logical range 0..1
Input id=1 size=8 count=6 page=Keyboard usage=Reserved_(no_event_indicated), logical
range 0..255
End collection
Collection page=Consumer usage=Consumer_Control
Input id=2 size=1 count=1 page=Consumer usage=Mute Variable, logical range 0..1
Input id=2 size=1 count=1 page=Consumer usage=Stop Variable, logical range 0..1
Input id=2 size=1 count=1 page=Consumer usage=0x00cd Variable, logical range 0..1
Input id=2 size=1 count=1 page=Consumer usage=Volume_Down Variable, logical range
0..1
Input id=2 size=1 count=1 page=Consumer usage=Volume_Up Variable, logical range 0..1
Input id=2 size=1 count=1 page=Consumer usage=Scan_Previous_Track Variable, logical
range 0..1
Input id=2 size=1 count=1 page=Consumer usage=Scan_Next_Track Variable, logical
range 0..1
Input id=2 size=1 count=1 page=Consumer usage=AL_Consumer_Control_Configuration
Variable, logical range 0..1
Input id=2 size=1 count=1 page=Consumer usage=AC_Undo Variable, logical range 0..1
Input id=2 size=1 count=1 page=Consumer usage=0x0279 Variable, logical range 0..1
Input id=2 size=1 count=1 page=Consumer usage=0x01ab Variable, logical range 0..1
Input id=2 size=1 count=1 page=Consumer usage=AC_Print Variable, logical range 0..1
Input id=2 size=1 count=1 page=Consumer usage=AC_Open Variable, logical range 0..1
Input id=2 size=1 count=1 page=Consumer usage=AC_Close Variable, logical range 0..1
Input id=2 size=1 count=1 page=Consumer usage=AC_Save Variable, logical range 0..1
Input id=2 size=1 count=1 page=Consumer usage=AC_New Variable, logical range 0..1
Input id=2 size=1 count=1 page=Consumer usage=AL_Calculator Variable, logical range
0..1
Input id=2 size=1 count=1 page=Consumer usage=AL_Logoff Variable, logical range 0..1
Input id=2 size=1 count=1 page=Consumer usage=Help Variable, logical range 0..1
Input id=2 size=1 count=1 page=Consumer usage=AC_Home Variable, logical range 0..1
Input id=2 size=1 count=1 page=Consumer usage=0x0289 Variable, logical range 0..1
Input id=2 size=1
[PATCH] libusbhid(3) should not clear report_size field
Dear Hackers, while working on bluetooth hid implementation i found out that libusbhid(3) has minor problem. it turns out that netbsd folks already fixed this. http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libusbhid/parse.c.diff?sortby=dater1=1.4r2=1.5f=u so, i'd like to commit the patch below. who is our resident USB HID expert? please speak up if there is any problem, concern or objection. thanks, max freefall% scvs diff -u src/lib/libusbhid cvs server: Diffing src/lib/libusbhid Index: src/lib/libusbhid/parse.c === RCS file: /home/ncvs/src/lib/libusbhid/parse.c,v retrieving revision 1.8 diff -u -r1.8 parse.c --- src/lib/libusbhid/parse.c 9 Apr 2003 01:52:48 - 1.8 +++ src/lib/libusbhid/parse.c 26 Jan 2004 22:25:26 - @@ -86,7 +86,6 @@ c-string_minimum = 0; c-string_maximum = 0; c-set_delimiter = 0; - c-report_size = 0; } hid_data_t __ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Darwin/OSX Bluetooth code
Peter, I'm currently thinking about un-Netgraph'ing FreeBSD code to make it portable to other BSD style systems. I'm trying to look at other implementations and learn as much as i can. In particular i'm trying to figure out how to minimize OS dependent code and what is the right abstractions levels. When I saw your BlueTooth entry in the recent status report, I thought I'd comment on that, but then got distracted :) You've done some great work on BlueTooth. IMHO, it would be a mistake Thank you. to try to un-NetGraph it; there have been lots of rumours about people porting the NetGraph framework to other OS's, and if BlueTooth support will provide yet one more reason for the need to do this, so be it :) I'm not so sure about these rumors. To me it looks like NetBSD and OpenBSD folks are reluctant to adopt/port Netgraph. Also, when i started this project, few people have pointed out that it would much better if other BSDs could share the code. NetGraph is a wonderful framework for writing drivers, and not limited to network drivers, either - as you have no doubt discovered so far - there should be no need to give up its advantages if it's possible to retain them and even gain much in portability for the writing of future drivers (should NetGraph run on more OS's). I could not agree more. Netgraph is extremely flexible and when it comes to a rapid prototype development it is a number one choice. However, the fact is Netgraph is FreeBSD only framework (at least for now). So i think all BSDs would benefit from the common code (and as an extra bonus FreeBSD could have Netgraph support :) thanks, max __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Darwin/OSX Bluetooth code
Dear Hackers, Does anyone know if Apple has released Darwin/OSX Bluetooth code to the public? Quick look at http://www.opensource.apple.com/ did not reveal anything particularly useful (although i did not try really hard :) I'm currently thinking about un-Netgraph'ing FreeBSD code to make it portable to other BSD style systems. I'm trying to look at other implementations and learn as much as i can. In particular i'm trying to figure out how to minimize OS dependent code and what is the right abstractions levels. thanks, max __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ax88172 vs FreeBSD USB stack
Just FYI ng_ubt(4) (/sys/netgraph/bluetooth/drivers/ubt) driver (Bluetooth USB devices) makes use of two interfaces. thanks, max Bernd Walter wrote: On Fri, Mar 28, 2003 at 10:38:58AM -0800, Bill Paul wrote: So. I picked up a Linksys USB200M USB 2.0 ethernet adapter that uses the ASIX Electronics AX88172 chip, and I started cobbling together a driver. This chip uses a series of vendor specific commands to do things like read/write the MII management interface on the MAC, read/write the SROM, set the RX filter, multicast hash table, etc. I can do all this no problem. The Linksys NIC uses a RealTek 8201L PHY, and I can attach it and negotiate a link. However I can't send or receive any packets. Like all the other USB NICs, packet transfer is supposed to done via bulk in/bulk out endpoints, and I can open these endpoints and initiate transfers just fine, but nothing ever happens. Transmit attempts don't yield any packets on the wire, and I never get any RX transfer completions. (I can see the activity LED on the NIC blink when a frame arrives though.) One thing I have not attempted to do yet (but may try this weekend) is to directly read the RX or TX SRAM (there are commands to let you do this). Frankly, I'm a bit stumped. It looks as though I'm doing everything correctly, but I can't explain why the bulk transfers don't work. Clearly, the control endpoint works, since I can issue commands. There doesn't appear to be any special command that one has to issue to enable/disable the receiver or transmitter on the MAC. I have only one possible explanation. The manual for the AX88172 (http://www.freebsd.org/~wpaul/ASIX/Ax88172.PDF) says the following: The AX88172 supports 2 interfaces, the interface 0 is Data Interface and interface 1 is for Communication interface. If that is true - the device has a strange design. Normaly devices use single interfaces with multiple commucations channels. An interface in USB wording is something like a virtual device - similar to functions on pci. E.g. you can have an umass device on interface 0 and a keyboard on interface 1. The FreeBSD USB stack supports mutltiple interfaces, but currently doesn't support probing different drivers for different interfaces on the same device. However you can try usbctl from usbutils to get an overview of the device. I have made a port, it is actually being reviewed by a port commiter, which you can get on: http://www.cosmo-project.de/~bernd/usbutil.tgz However the USB stack disagrees with the manual on this point: it steadfastly insists that configuration 1 has only 1 interface. So my question, for any USB gurus out there, is: is it possible that the USB stack is wrong on this point, and I really need to be using interface 1 for bulk in/out transfers? I'm a little suspicious at this point, because the stack can't seem to even read the device ID string correctly. (It identifies the chip only as vendor 0x77b, device 0x2226.) Strange - let us see what usbctl says - it never failed for me. BTW: I doubt that USB 1.x vs USB 2.0 make a difference in the problem you are seeing, but in case you want to test later. The EHCI patch is available under: http://www.cosmo-project.de/~bernd/ehci.patch It is currently not tested against any device, but the controller probes fine and scanning the root hub (without devices) did not fail. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ax88172 vs FreeBSD USB stack
ng_ubt(4) (/sys/netgraph/bluetooth/drivers/ubt) driver (Bluetooth USB devices) makes use of two interfaces. From a look into the driver these interfaces serve different protocols. not sure what do you mean by protocol here. interface 0 has control, interrupt, bulk-in and bulk-out endpoints. interface 1 has isoc-in and isoc-out endpoints. also interface 1 has 5 different configurations (w/different packet sizes) allowing isoc. bandwidth scaling. I asume they are unrelated from a logical standpoint, but I don't know bluetooth technology. they are. interface 0 is used to control device (control/interrupt transfers) and to transfer data (via bulk-in/out transfers). interface 1 is used to transfer voice (via isoc. transfers). We have a similar situation with ulpt, where we usually have up to three interfaces with different capabilities. ulpt currently pics one of them, but we could also have three different ulpt instances taking each one of them. it is not exactly the same here. the device can only perform 1) data transfers 2) data transfers + voice transfers Well the AC88172 PDF is very clear about having 2 interfaces. The document also speaks about 4 endpoints, which I expect to be on interface 0 as they also have listed endpoint number 0 - they don't tell in the document. What I currently don't know is why there are 2 interfaces. The document also mentions some homenet capabilities on RJ11 - whatever it means. Maybe it's an hardware optional interface, which is disabled in this special device. in Bluetooth case they decided to put isoc. endpoints on the another interface so you can scale isoc. bandwidth (via max. packet size) without affecting the other transfers. thanks, max ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH2] PPP in -direct mode does not execute any chat scripts
Hello Brian, Yes, this looks fine, although I think this shows that the -direct description is wrong. Perhaps this is more appropriate: -direct This is used for communicating over an already established connection, usually when receiving incoming connections accepted by getty(8). ppp ignores the ``set device'' line and uses descriptor 0 as the link. ppp will ignore any configured chat scripts unless the ``force-scripts'' option has been enabled. If callback Do you agree with this description ? If so, I'll go ahead and commit the yes, this is more accurate description. i missed it. changes. Just to be picky, I'll re-sort the OPT_ variables too :*P no problem :) And thanks for the patches. thank you for reviewing them :) max On Mon, 03 Feb 2003 14:45:37 -0800, Maksim Yevmenkin wrote: Dear Brian and Hackers, Please find updated proposed version of the patch. As suggested by Warner option has been renamed to 'force-sripts' and now works for both 'direct' and 'dedicated' modes. Also as suggested by Terry the man page has been updated to document side effect of 'direct'. -direct This is used for receiving incoming connections. ppp ignores the ``set device'' line and uses descriptor 0 as the link. ppp will never use any configured chat scripts unless ``force-scripts'' option has been enabled. If callback is configured, ppp will use the ``set device'' infor- mation when dialing back. -dedicated This option is designed for machines connected with a dedicated wire. ppp will always keep the device open and will never use any configured chat scripts unless ``force-scripts'' option has been enabled. force-scripts Default: Disabled. Forces execution of the configured chat scripts in direct and dedicated modes. Please find attached patch that adds new option to the PPP. run-scripts-in-direct-mode Default: Disabled. This allows to run chat scripts in direct mode. did i miss anything? objections? comments? reviews? First comment: run it past Brian Somers [EMAIL PROTECTED]; it's his baby, and he's the active maintainer. I have sent him e-mail. Rest of comments: Actually, why doesn't -direct allow a chat script by default? The man page doesn't document that as a side-effect of -direct, only of -dedicated, but it's been there since the import. Should this really be a negotiate section command, rather than just a command or a set command? Also, there are only two other commands even have a - in them, and both of them only have one (just seems a little long, compared to, say, rsid or direct-with-script, or even force-script). Personal preference: don't make it conditional on -direct, let it also work with -dedicated, and call it force-script or something, instead. done The man page should be updated -- including the undocumented side-effect of -direct disabling scripts). done thanks max ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Need an expert's advise on WITNESS problem(?) (very long)
Dear Hackers,
I need an expert's advice on the small locking/WITNESS problem
(if this is a real problem of course). It basically boils down
to the following:
Consider three (3) MTX_DEF mutexes: A, B1 and B2. Mutex A has a
name mutex_A and type type_A. Mutex B1 has a name mutex_B1
and mutex B2 has name mutex_B2. Both mutex B1 and B2 have the
same type type_B. Please note that mutexes B1 and B2 are
completely independent from each other. They just have the same
mutex type (B1 and B2 are used for fine grained locking).
Now consider the code that has two (2) paths: P1 and P2.
On the path P1 the code first acquires mutex A and then mutex
B1. Then the code releases mutex B1 and then mutex A.
On the path P2 the code first acquires mutex B2 and then mutex
A. Then the code releases mutex B2 and then mutex A.
So the code's flow looks something like this
--\ /-- B1 -- Code path P1
A
--/ \-- B2 -- Code path P2
Now the problem (again if this is a problem) is that WITNESS
code builds relations between mutex types (or at least I think
it does). So when the code runs, WITNESS will build relations
between mutex types for the first path the code follows (lets
say P1). Later when the code follows the second path (in this
example P2), WITNESS will create lock order reversal message.
The questions are:
1) Is anything wrong with the such code and/or mutex use?
Since mutexes B1 and B2 are completely independent, there
is no deadlock danger, right? Please tell me if I'm wrong
and missing something here.
2) Is there any way to resolve the problem? I'm prepared to
change/re-design my code if needed.
3) Is WITNESS right in this case?
I have attached a small spherical cow that demonstrates
the example above. Just compile and load ng_cow.ko module
and then try
# ngctl msg cow: moo
Please advise.
thanks,
max
Makefile
CFLAGS+=-g
KMOD= ng_cow
SRCS= ng_cow.c
NOMAN=
.include bsd.kmod.mk
=== ng_cow.c ==
#include sys/param.h
#include sys/systm.h
#include sys/errno.h
#include sys/kernel.h
#include sys/lock.h
#include sys/malloc.h
#include sys/mbuf.h
#include sys/mutex.h
#include netgraph/ng_message.h
#include netgraph/netgraph.h
#include netgraph/ng_parse.h
#define NG_COW_NODE_TYPEcow
#define NGM_COW_COOKIE 1018303300
#define NGM_COW_MOO 1
#ifdef NG_SEPARATE_MALLOC
MALLOC_DEFINE(M_NETGRAPH_COW, cow, Netgraph spherical cow);
#else
#define M_NETGRAPH_COW M_NETGRAPH
#endif
static ng_constructor_t ng_cow_constructor;
static ng_rcvmsg_t ng_cow_rcvmsg;
static ng_shutdown_tng_cow_shutdown;
static ng_newhook_t ng_cow_newhook;
static ng_connect_t ng_cow_connect;
static ng_rcvdata_t ng_cow_rcvdata;
static ng_disconnect_t ng_cow_disconnect;
static int ng_cow_modevent (module_t, int, void *);
static const struct ng_cmdlist ng_cow_cmdlist[] = {
{
NGM_COW_COOKIE,
NGM_COW_MOO,
moo,
NULL,
NULL
},
{ 0, }
};
static struct ng_type typestruct = {
NG_ABI_VERSION,
NG_COW_NODE_TYPE, /* typename */
ng_cow_modevent,/* modevent */
ng_cow_constructor, /* constructor */
ng_cow_rcvmsg, /* control message */
ng_cow_shutdown,/* destructor */
ng_cow_newhook, /* new hook */
NULL, /* find hook */
ng_cow_connect, /* connect hook */
ng_cow_rcvdata, /* data */
ng_cow_disconnect, /* disconnect hook */
ng_cow_cmdlist /* node command list */
};
NETGRAPH_INIT(cow, typestruct);
MODULE_VERSION(ng_cow, 1);
static node_p the_node = NULL;
static struct mtx a, b1, b2;
static int
ng_cow_modevent(module_t mod, int event, void *data)
{
int error = 0;
switch (event) {
case MOD_LOAD:
error = ng_make_node_common(typestruct, the_node);
if (error != 0)
break;
error = ng_name_node(the_node, NG_COW_NODE_TYPE);
if (error != 0) {
NG_NODE_UNREF(the_node);
the_node = NULL;
break;
}
mtx_init(a, mutex_A, type_A, MTX_DEF);
mtx_init(b1, mutex_B1, type_B, MTX_DEF);
mtx_init(b2, mutex_B2, type_B, MTX_DEF);
break;
case MOD_UNLOAD:
mtx_destroy(a);
mtx_destroy(b1);
mtx_destroy(b2);
break;
default:
error = EOPNOTSUPP;
break;
}
return (error);
}
static int
ng_cow_constructor(node_p node)
{
return (EINVAL);
}
static int
ng_cow_newhook(node_p node, hook_p hook, char const *name)
{
return
[PATCH] PPP in -direct mode does not execute any chat scripts
Dear Hackers,
Please find attached patch that adds new option to the PPP.
run-scripts-in-direct-mode
Default: Disabled. This allows to run chat scripts in
direct mode.
did i miss anything? objections? comments? reviews?
thanks,
max
I'm working on the Bluetooth stack for FreeBSD and currently
doing testing for new in-kernel RFCOMM code. RFCOMM is a way
to emulate serial link over Bluetooth.
In particular Bluetooth spec defines two RFCOMM based profiles
LAN (Network Access profile) and DUN (DialUp Networking profile).
Both profiles use PPP.
My current in-kernel RFCOMM code provides SOCK_STREAM sockets
interface, i.e. when application wants to talk RFCOMM it just
opens a socket. The next step is to run PPP, so the launcher
program opens RFCOMM connection then dup() socket to stdin and
stdout and exec() PPP in direct mode.
Everything works great for the LAN profile, where null-modem
connection is assumed and both client and server start talking
PPP right after RFCOMM connection is established.
However the DUN profile is more tricky. In this scenario client
just connected to the virtual serial port on the server. Now to
start PPP session client must dial a number. i.e. there is
still need for a little chat script.
Here is an example:
1) I'd like to use my GPRS and Bluetooth enabled cell phone to
access the Internet
2) I open a RFCOMM connection to the cell phone and get connected
to the virtual serial port on the cell phone.
3) Now i must dial a special GRPS number, i.e. something like
ATD*98***1# and wait for CONNECT string from the phone
4) Now i can talk PPP.
So the questions is: would it be possible to enable PPP chat
in direct mode? Is there any reason to not allow this? It
seems 'login' script would do just fine. Is there any other/
better way to do this? One possible option right now is to
execute /bin/chat from the launcher program before executing
PPP, but i'd rather keep all chat scripts in PPP.
thanks,
max
diff -ru8 ppp.orig/bundle.h ppp/bundle.h
--- ppp.orig/bundle.h Mon Feb 3 10:34:44 2003
+++ ppp/bundle.hMon Feb 3 10:36:56 2003
@@ -44,16 +44,17 @@
#define OPT_LOOPBACK 0x0040
#define OPT_PASSWDAUTH 0x0080
#define OPT_PROXY 0x0100
#define OPT_PROXYALL 0x0200
#define OPT_SROUTES0x0400
#define OPT_TCPMSSFIXUP0x0800
#define OPT_THROUGHPUT 0x1000
#define OPT_UTMP 0x2000
+#define OPT_RSIDM 0x4000 /* run-scripts-in-direct-mode */
#define MAX_ENDDISC_CLASS 5
#define Enabled(b, o) ((b)-cfg.opt (o))
/* AutoAdjust() values */
#define AUTO_UP1
#define AUTO_DOWN 2
diff -ru8 ppp.orig/command.c ppp/command.c
--- ppp.orig/command.c Mon Feb 3 10:34:45 2003
+++ ppp/command.c Mon Feb 3 10:57:05 2003
@@ -2851,29 +2851,32 @@
{loopback, NULL, OptSet, LOCAL_AUTH, Loop packets for local iface,
disable|enable, (const void *)OPT_LOOPBACK},
{passwdauth, NULL, OptSet, LOCAL_AUTH, Use passwd file,
disable|enable, (const void *)OPT_PASSWDAUTH},
{proxy, NULL, OptSet, LOCAL_AUTH, Create a proxy ARP entry,
disable|enable, (const void *)OPT_PROXY},
{proxyall, NULL, OptSet, LOCAL_AUTH, Proxy ARP for all remote hosts,
disable|enable, (const void *)OPT_PROXYALL},
+ {run-scripts-in-direct-mode, NULL, OptSet, LOCAL_AUTH,
+ Run char scripts in direct mode, disable|enable,
+ (const void *)OPT_RSIDM},
{sroutes, NULL, OptSet, LOCAL_AUTH, Use sticky routes,
disable|enable, (const void *)OPT_SROUTES},
{tcpmssfixup, mssfixup, OptSet, LOCAL_AUTH, Modify MSS options,
disable|enable, (const void *)OPT_TCPMSSFIXUP},
{throughput, NULL, OptSet, LOCAL_AUTH, Rolling throughput,
disable|enable, (const void *)OPT_THROUGHPUT},
{utmp, NULL, OptSet, LOCAL_AUTH, Log connections in utmp,
disable|enable, (const void *)OPT_UTMP},
#ifndef NOINET6
-#define OPT_MAX 13 /* accept/deny allowed below and not above */
+#define OPT_MAX 14 /* accept/deny allowed below and not above */
#else
-#define OPT_MAX 11
+#define OPT_MAX 12
#endif
{acfcomp, NULL, NegotiateSet, LOCAL_AUTH | LOCAL_CX,
Address Control field compression, accept|deny|disable|enable,
(const void *)NEG_ACFCOMP},
{chap, chap05, NegotiateSet, LOCAL_AUTH | LOCAL_CX,
Challenge Handshake Authentication Protocol, accept|deny|disable|enable,
(const void *)NEG_CHAP05},
diff -ru8 ppp.orig/datalink.c ppp/datalink.c
--- ppp.orig/datalink.c Mon Feb 3 10:34:45 2003
+++ ppp/datalink.c Mon Feb 3 11:03:48 2003
@@ -956,17 +956,18 @@
free(dl);
return result;
}
void
datalink_Up(struct datalink *dl, int runscripts, int packetmode)
{
- if (dl-physical-type (PHYS_DIRECT|PHYS_DEDICATED))
+ if ((dl-physical-type PHYS_DEDICATED) ||
+ ((dl-physical-type PHYS_DIRECT) !Enabled(dl-bundle, OPT_RSIDM)))
/* Ignore scripts */
runscripts = 0;
switch (dl-state) {
case DATALINK_CLOSED:
if (bundle_Phase(dl-bundle) == PHASE_DEAD ||
bundle_Phase(dl-bundle) ==
[PATCH2] PPP in -direct mode does not execute any chat scripts
Dear Brian and Hackers,
Please find updated proposed version of the patch. As suggested by
Warner option has been renamed to 'force-sripts' and now works for
both 'direct' and 'dedicated' modes. Also as suggested by Terry the
man page has been updated to document side effect of 'direct'.
-direct
This is used for receiving incoming connections. ppp ignores the
``set device'' line and uses descriptor 0 as the link. ppp will
never use any configured chat scripts unless ``force-scripts''
option has been enabled.
If callback is configured, ppp will use the ``set device'' infor-
mation when dialing back.
-dedicated
This option is designed for machines connected with a dedicated
wire. ppp will always keep the device open and will never use
any configured chat scripts unless ``force-scripts'' option has
been enabled.
force-scripts
Default: Disabled. Forces execution of the configured chat
scripts in direct and dedicated modes.
Please find attached patch that adds new option to the PPP.
run-scripts-in-direct-mode
Default: Disabled. This allows to run chat scripts in
direct mode.
did i miss anything? objections? comments? reviews?
First comment: run it past Brian Somers [EMAIL PROTECTED]; it's
his baby, and he's the active maintainer.
I have sent him e-mail.
Rest of comments:
Actually, why doesn't -direct allow a chat script by default?
The man page doesn't document that as a side-effect of -direct,
only of -dedicated, but it's been there since the import.
Should this really be a negotiate section command, rather than
just a command or a set command?
Also, there are only two other commands even have a - in them,
and both of them only have one (just seems a little long, compared
to, say, rsid or direct-with-script, or even force-script).
Personal preference: don't make it conditional on -direct, let
it also work with -dedicated, and call it force-script or
something, instead.
done
The man page should be updated -- including the undocumented
side-effect of -direct disabling scripts).
done
thanks
max
diff -ru8 ppp.orig/bundle.h ppp/bundle.h
--- ppp.orig/bundle.h Mon Feb 3 10:34:44 2003
+++ ppp/bundle.hMon Feb 3 14:08:06 2003
@@ -44,16 +44,17 @@
#define OPT_LOOPBACK 0x0040
#define OPT_PASSWDAUTH 0x0080
#define OPT_PROXY 0x0100
#define OPT_PROXYALL 0x0200
#define OPT_SROUTES0x0400
#define OPT_TCPMSSFIXUP0x0800
#define OPT_THROUGHPUT 0x1000
#define OPT_UTMP 0x2000
+#define OPT_FORCE_SCRIPTS 0x4000 /* force chat scripts */
#define MAX_ENDDISC_CLASS 5
#define Enabled(b, o) ((b)-cfg.opt (o))
/* AutoAdjust() values */
#define AUTO_UP1
#define AUTO_DOWN 2
diff -ru8 ppp.orig/command.c ppp/command.c
--- ppp.orig/command.c Mon Feb 3 10:34:45 2003
+++ ppp/command.c Mon Feb 3 14:26:37 2003
@@ -2830,16 +2830,19 @@
return 0;
}
static struct cmdtab const NegotiateCommands[] = {
{filter-decapsulation, NULL, OptSet, LOCAL_AUTH,
filter on PPPoUDP payloads, disable|enable,
(const void *)OPT_FILTERDECAP},
+ {force-scripts, NULL, OptSet, LOCAL_AUTH,
+ Force execution of the configured chat scripts, disable|enable,
+ (const void *)OPT_FORCE_SCRIPTS},
{idcheck, NULL, OptSet, LOCAL_AUTH, Check FSM reply ids,
disable|enable, (const void *)OPT_IDCHECK},
{iface-alias, NULL, IfaceAliasOptSet, LOCAL_AUTH,
retain interface addresses, disable|enable,
(const void *)OPT_IFACEALIAS},
#ifndef NOINET6
{ipcp, NULL, OptSet, LOCAL_AUTH, IP Network Control Protocol,
disable|enable, (const void *)OPT_IPCP},
@@ -2861,19 +2864,19 @@
{tcpmssfixup, mssfixup, OptSet, LOCAL_AUTH, Modify MSS options,
disable|enable, (const void *)OPT_TCPMSSFIXUP},
{throughput, NULL, OptSet, LOCAL_AUTH, Rolling throughput,
disable|enable, (const void *)OPT_THROUGHPUT},
{utmp, NULL, OptSet, LOCAL_AUTH, Log connections in utmp,
disable|enable, (const void *)OPT_UTMP},
#ifndef NOINET6
-#define OPT_MAX 13 /* accept/deny allowed below and not above */
+#define OPT_MAX 14 /* accept/deny allowed below and not above */
#else
-#define OPT_MAX 11
+#define OPT_MAX 12
#endif
{acfcomp, NULL, NegotiateSet, LOCAL_AUTH | LOCAL_CX,
Address Control field compression, accept|deny|disable|enable,
(const void *)NEG_ACFCOMP},
{chap, chap05, NegotiateSet, LOCAL_AUTH | LOCAL_CX,
Challenge Handshake Authentication Protocol, accept|deny|disable|enable,
(const void *)NEG_CHAP05},
diff -ru8 ppp.orig/datalink.c ppp/datalink.c
--- ppp.orig/datalink.c Mon Feb 3 10:34:45 2003
+++ ppp/datalink.c Mon Feb 3 14:17:52 2003
@@ -956,17 +956,18 @@
free(dl);
return result;
}
void
datalink_Up(struct datalink *dl, int runscripts, int packetmode)
{
- if (dl-physical-type (PHYS_DIRECT|PHYS_DEDICATED))
+ if (!Enabled(dl-bundle, OPT_FORCE_SCRIPTS)
+ (dl-physical-type (PHYS_DIRECT|PHYS_DEDICATED)))
/* Ignore scripts */
runscripts = 0;
Re: [PATCH2] PPP in -direct mode does not execute any chat scripts
Terry, Maksim Yevmenkin wrote: force-scripts Default: Disabled. Forces execution of the configured chat scripts in direct and dedicated modes. Outstanding! If Brian doesn't veto, I'd say it's gold, and someone should commit it; so I guess this fixes the last Bluetooth Cell phone PPP problem, right? seems like it :) just got report back from one of the testers. he got connected to the internet over his T39m bluetooth enabled cell phone. the cool thing is that you can make CSD, GPRS or HSCSD calls. its just a matter of init string you send to the phone :) still waiting on t68i and Nokia 7650 reports. PS: I can't believe that Warner and I came within one letter of suggesting the same option name. 8-) 8-). :) thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: [PATCH2] PPP in -direct mode does not execute any chat scripts
Terry, seems like it :) just got report back from one of the testers. he got connected to the internet over his T39m bluetooth enabled cell phone. the cool thing is that you can make CSD, GPRS or HSCSD calls. its just a matter of init string you send to the phone :) still waiting on t68i and Nokia 7650 reports. What kind of security negotiation occurs between devices, or can I use anyone's cell phone, as long as we are in the same restaurant, and I get a table in the middle? 8-) 8-). you can if person with the cell phone is stupid :) and you do not have to get table in the middle. you have to be within ~10 meters radius. you also can get access to person's address book, calendar etc. as well :) all authentication and encryption based around link keys. one link key for each pair of devices. link key can be: 1) programmed into device itself (up to 16 keys) 2) can be requested from the user via HCI events 3) can be generated from the PIN code, PIN code is requested from the user via HCI event. normally what happens is: 1) device A tries to connect to device B 2) device B now looks for the link key that corresponds to device A's BDADDR. if found then key is used 3) if no link key found then both device A and device B locally generate Link_Key_Request event 4) both device A and B either get the keys from user A and user B, or if there is still no link key user sends Link_Key_Negative_Reply command 5) if no link key was received then both devices locally generate PIN_Code_Request 6) now both user A and user B have to enter PIN codes. the link key will be calculated from the PIN code. if no PIN code exists then user sends PIN_Code_Negative_Reply command to the device. this is implemented inside hcsecd. the user has option to disable authentication and in this case anyone can connect and no link key is required. also user can prevent device from peforming inquiry scan, i.e. the device will not respond to inquiry requests from other devices. user also can prevent device from performing page scans, i.e. device will not accept connections. thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
PPP in -direct mode does not execute any chat scripts
Dear Hackers, I'm working on the Bluetooth stack for FreeBSD and currently doing testing for new in-kernel RFCOMM code. RFCOMM is a way to emulate serial link over Bluetooth. In particular Bluetooth spec defines two RFCOMM based profiles LAN (Network Access profile) and DUN (DialUp Networking profile). Both profiles use PPP. My current in-kernel RFCOMM code provides SOCK_STREAM sockets interface, i.e. when application wants to talk RFCOMM it just opens a socket. The next step is to run PPP, so the launcher program opens RFCOMM connection then dup() socket to stdin and stdout and exec() PPP in direct mode. Everything works great for the LAN profile, where null-modem connection is assumed and both client and server start talking PPP right after RFCOMM connection is established. However the DUN profile is more tricky. In this scenario client just connected to the virtual serial port on the server. Now to start PPP session client must dial a number. i.e. there is still need for a little chat script. Here is an example: 1) I'd like to use my GPRS and Bluetooth enabled cell phone to access the Internet 2) I open a RFCOMM connection to the cell phone and get connected to the virtual serial port on the cell phone. 3) Now i must dial a special GRPS number, i.e. something like ATD*98***1# and wait for CONNECT string from the phone 4) Now i can talk PPP. So the questions is: would it be possible to enable PPP chat in direct mode? Is there any reason to not allow this? It seems 'login' script would do just fine. Is there any other/ better way to do this? One possible option right now is to execute /bin/chat from the launcher program before executing PPP, but i'd rather keep all chat scripts in PPP. thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: PPP in -direct mode does not execute any chat scripts
Daniel, So the questions is: would it be possible to enable PPP chat in direct mode? Is there any reason to not allow this? It seems 'login' script would do just fine. Is there any other/ better way to do this? One possible option right now is to execute /bin/chat from the launcher program before executing PPP, but i'd rather keep all chat scripts in PPP. You'd need to add an option to do this - enabling it by default would break a lot of stuff (eg I use ppp -direct for incoming PPP calls). If -direct *by default* used chat then I would have to change my ppp.conf and that would suck :) Perhaps have 'enable usechatindirect' or some such.. i agree, it would break things if the 'default' section in the ppp.conf has 'set dial foo' and 'set login bar' lines in it (which is most likely the case) *and* if you use the same ppp.conf for both dialing out and receiving calls. in order to make things work people would have to put 'set dial' and 'set login' lines for the labels used in 'direct' mode. i guess it is better to add the option. back to PPP hacking then :) thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: PPP in -direct mode does not execute any chat scripts
Warner,
Is there any reason that RFCOMM doesn't give full tty support, like
the various USB modem drivers do? That's likely the best way to deal
with this. Then ppp or whatever application you want will just work.
Yes, there is. RFCOMM connection can only be established when
baseband link is open. Also RFCOMM connection exists between
pair of device and identified by source address, destination
address and channel. In fact up to 60 RFCOMM channels can exist
on the same baseband link between the same pair of devices.
So, with tty device things look a bit weird. for example if
user wants to dial out then user must do three things:
1) establish binding between source, destination address, channel
and particular tty device;
2) open RFCOMM channel on the tty device;
3) start PPP on the tty device.
Things gets even more tricky when you want to run server
on specific RFCOMM channel. In this case tty device does not
exist at all until RFCOMM connection is establised. So it is
really hard to do binding between connection and tty device.
May be if we could clone tty devices then if would be easier.
Also Bluetooth spec. has redefined some aspects of GSM 07.10
spec. and all Bluetooth 1.1 devices do not use modem signals
defined in GSM 07.10. Instead there is something called
'credit based flow control'.
So you see it is probably possible to build a tty-like interface,
but i do not think it really worth the trouble. In fact one
can do it right now with the help of nmdm(4) driver. It is a
simple wrapper that would pass the data between socket and
/dev/nmdm0{A|B}.
thanks,
max
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
RE: PPP in -direct mode does not execute any chat scripts
Daniel, Is there any reason that RFCOMM doesn't give full tty support, like the various USB modem drivers do? That's likely the best way to deal with this. Then ppp or whatever application you want will just work. Maybe it is necessary/useful to 'steer' PPP from the RFCOMM end? eg 'when you get a connection from this device connect via PPP on stdin/stdout' yes. that is one example. but the real trouble with tty is the server application that wants to listen on wildcard address. for example Network Access point that listens on RFCOMM channel 1. no matter what client comes in the server will just accept connection on the socket, fork and run PPP in direct mode. also there are other things besides PPP that use RFCOMM. OBEX is another example, where clients will put/get objects from the server. Still I guess you could just run 'ppp rfcomm' instead.. it will only work for in RFCOMM client case. i do not know how to build server applications with tty interface (pty's do not count :) thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: PPP in -direct mode does not execute any chat scripts
Warner,
: So you see it is probably possible to build a tty-like interface,
: but i do not think it really worth the trouble. In fact one
: can do it right now with the help of nmdm(4) driver. It is a
: simple wrapper that would pass the data between socket and
: /dev/nmdm0{A|B}.
That's one way.
too many moving parts :)
Another is to have some control program that interacts with RFCOMM to
establish a 'connection' between endpoints and sets the various
parameters and gives userland access to it as a tty.
sure, but userland somehow *must* know which tty to use. only
control program knows which tty it just created, so the control
program *must* run userland and *must* tell which tty to use.
again if you want to run server, than control program somehow
must be informed that incomming connections on RFCOMM channel X
should be handled by server application Y.
all this make control program somewhat like inetd.
my point is that in most cases you do not need all this stuff.
there is no point in tty interface. even if you do something
like wireless printing (BTW this also goes via RFCOMM). all
you need to do is just setup filter that would accept data,
open RFCOMM connection and feed data into printer via RFCOMM.
barring that, you'll may be able to run chat on stdin/stdout before
ppp gets into the act and get the number dialed that way and have ppp
-direct run afterwards.
that's another option. but why duplicate the code and make things
more complicated for user? why user have to setup additional chat
script just to dial a GPRS number? if i add 'enable scripts-in-direct-mode'
option to PPP all user would have to do is to add 'set dial script'
line and take advantage of all wonderful things that PPP chat can
do :) i think PPP is the right place for it.
i would try to create the patches for PPP and submit them for
review. it should not be that hard. or perhaps i could fallback
to old pppd(8) that seems does not have this limitation.
thanks,
max
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
RE: PPP in -direct mode does not execute any chat scripts
Daniel, yes. that is one example. but the real trouble with tty is the server application that wants to listen on wildcard address. for example Network Access point that listens on RFCOMM channel 1. no matter what client comes in the server will just accept connection on the socket, fork and run PPP in direct mode. also there are other things besides PPP that use RFCOMM. OBEX is another example, where clients will put/get objects from the server. OK, it is a pity you can't define variables when invoking PPP I guess :) Still I guess you could just run 'ppp rfcomm' instead.. it will only work for in RFCOMM client case. i do not know how to build server applications with tty interface (pty's do not count :) Heh, I use birda for IRDA, it's strictly userland and uses pty's.. Works really well :) pty does not save you here. original RFCOMM code is a 100% userland and uses pty's. the original code redirects pty's slave side to stdin/stdout and runs PPP in -direct mode. also all bluetooth devices make use of something called SDP (Service Discovery Protocol) this is the way to advertise the service to the rest of the world. now with tty interface the server application will only be launched when connection is established and tty exits. but in order to establish RFCOMM connection clients must first talk SDP to figure out what services are available on which RFCOMM channel. thus something else must register services with local SDP daemon. with sockets interface there is no problem. server application just register service with local SDP daemon and listen()s on RFCOMM socket. when server application exits it removes service registration. thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: input source for network application
Steve Tremblett wrote: I've been toying with the idea of tackling a Netgraph TCP/IP implementation and want to hack out some skeleton netgraph nodes just to feel things out and play around with parsing. I'm somewhat confused on how to start. I'd like to be able to tinker as I go and I'd rather not have to write 5000 lines of code and complete a mini-stack before trying it out :) I'm in a bit of a bind. I want a sequence of ethernet frames to send up through this framework. Hooking to ng_ether will give me this but I am restricted to taking ALL frames (thus taking the machine offline) or orphaned frames (where I will have to write some sort of traffic generator to make frames of an invalid type). The third option here is to hack ng_ether to deliver frames out the lower hook as well as up into the kernel IP stack, thus giving me a complete stream without taking the box offline. I've gotten libnet which seems to fit the bill to generate any orphans I want, but making a stream of frames by hand is a pain. why do you need ng_ether, ng_tee etc. at all? can't you just write your code with assumption that there will be one (or few) input hooks? can't you just connect *user-space* Ethernet/IP frame generator to the input hook(s) and send frames? that's what i did in HCI/Bluetooth stack when i had no *real* Bluetooth hardware. i just wrote simple *user-space* Bluetooth device simulator and connected it to the stack. then i run VMWare and debug my code. you can use tcpdump and save dumps to the file and then just read it and re-inject them into your node. this way you can test at least basic stuff, i.e. frame parsing etc. I've read about ng_tee but haven't had an opportunity to play with it. Could I hack together something like this for an input source? Would this allow for uninterrupted operation of the workstation while also giving a stream of test data? kernel ip_input() \ \-| |- upper hook-\ ng_ether ng_tee |- lower hook-/ | wire In case that diagram doesn't display in your mailer, I'm thinking of connecting ng_tee to recieve input from ng_ether's lower hook and pass it out through ng_ether's upper hook as well as into the input hook of my own netgraph node. Does anyone have any suggestions or ideas on tools or methods to assist me in starting this venture? Am I thinking about this problem from the right angle or is my head up my ass? :) see above. max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
Ian Dowse wrote: In message p05111710b9c1484025de@[128.113.24.47], Garance A Drosihn writes: I also have a partition with freebsd-current from two or three days ago, and all the latest versions of the ports. Every time I try to start vmware2 on the newer system, the hardware dies. Sometimes it automatically reboots, other times it freezes up and I have to force-reboot it (sometimes by unplugging it from the wall). See the patch I posted in: http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=0+6285+/usr/local/www/db/text/2002/freebsd-emulation/20020908.freebsd-emulation There may still be further issues, but it allowed me to use vmware2 on a current from a week or two ago. you also might try to look at the patch in PR port/41784 http://www.freebsd.org/cgi/query-pr.cgi?pr=41784 i'm running vmware2 on my not so -current with the patch. if this is outdated feel free to close the PR. thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fast interrupts
John Baldwin wrote: On 26-Aug-2002 M. Warner Losh wrote: can you call wakeup(9) from a fast interrupt handler? [ ...] The only reason I ask is because sio seems to go out of its way to schedule a soft interrupt to deal with waking up processes, which then calls wakeup... Since wakeup only needs a spin lock, it is probably ok. You just can't call anything that would sleep (in any interrupt handler) or block on a non-spin mutex. what is the general locking technique for interrupt handlers? there must be some sort of locking, right? man atomic(9) says that current set of atomic operations do not necessarily guarantee atomicity across multiple processors. man mutex(9) says that MTX_DEF mutexes _might_ spin for some amount of time. but it is _only_ a machine specific optimization. MTX_SPIN are not recomended (correct me if i wrong). WITNESS gets upset when it finds unlisted MTX_SPIN mutex. for example NIC drivers call ether_input() from interrupt handlers which uses mutex to lock input queue. does that mean interrupt handler can/should use MTX_DEF mutex in this case? thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fast interrupts
Bosko Milekic wrote: On Mon, Aug 26, 2002 at 09:41:43AM -0700, Maksim Yevmenkin wrote: John Baldwin wrote: On 26-Aug-2002 M. Warner Losh wrote: can you call wakeup(9) from a fast interrupt handler? [ ...] The only reason I ask is because sio seems to go out of its way to schedule a soft interrupt to deal with waking up processes, which then calls wakeup... Since wakeup only needs a spin lock, it is probably ok. You just can't call anything that would sleep (in any interrupt handler) or block on a non-spin ^^ my understanding is that John was talking about any interrupt handler. Not just fast interrupt hander. mutex. what is the general locking technique for interrupt handlers? there must be some sort of locking, right? You are allowed to use mutex locks (both spin and MTX_DEF), only you are only allowed to user the former for fast interrupt handlers. thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Bug in m_split() ?
System Administrator wrote:
Your message
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Bug in m_split() ?
Sent:Wed, 10 Apr 2002 09:23:16 -0700
did not reach the following recipient(s):
[EMAIL PROTECTED] on Wed, 10 Apr 2002 09:23:21 -0700
The e-mail system was unable to deliver the message, but did not
report a specific reason. Check the address and try again. If it still
fails, contact your system administrator.
riffraff.plig.net #5.0.0 X-Postfix; unknown user:
freebsd-current
[EMAIL PROTECTED] on Wed, 10 Apr 2002 09:23:21 -0700
The e-mail system was unable to deliver the message, but did not
report a specific reason. Check the address and try again. If it still
fails, contact your system administrator.
riffraff.plig.net #5.0.0 X-Postfix; unknown user:
freebsd-hackers
Reporting-MTA: dns; ex-sj-5.digisle.com
Final-Recipient: RFC822; [EMAIL PROTECTED]
Action: failed
Status: 5.0.0
X-Supplementary-Info: riffraff.plig.net #5.0.0 X-Postfix; unknown user:
freebsd-current
X-Display-Name: [EMAIL PROTECTED]
Final-Recipient: RFC822; [EMAIL PROTECTED]
Action: failed
Status: 5.0.0
X-Supplementary-Info: riffraff.plig.net #5.0.0 X-Postfix; unknown user:
freebsd-hackers
X-Display-Name: [EMAIL PROTECTED]
Hackers,
i'm sorry for the wide distribution, but can anyone, please,
review the following patch to m_split() or at least comment
on it. i have attached another example that shows my problem.
--- uipc_mbuf.c.origMon Apr 8 14:40:23 2002
+++ uipc_mbuf.c Mon Apr 8 14:40:43 2002
@@ -584,6 +584,7 @@
if (remain MHLEN) {
/* m can't be the lead packet */
MH_ALIGN(n, 0);
+ n-m_len = 0;
n-m_next = m_split(m, len, wait);
if (n-m_next == NULL) {
(void) m_free(n);
thanks,
max
ng_cow.c.gz
Description: GNU Zip compressed data
Re: status of bluetooth support for FreeBSD?
Hackers, sorry for wide distribution. there are some news. i will submit full status report when its due (this weed i think) thanks, max Marco Molteni wrote: Hi all, I remember an email thread on -hackers last October on bluetooth support for FreeBSD: http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=589265+595599+/usr/local/www/db/text/2001/freebsd-hackers/20011007.freebsd-hackers There were two different projects, one in design phase (by John Kozubik [EMAIL PROTECTED]) and another (by Maksim Yevmenkin [EMAIL PROTECTED]) with already some beta code working. any news on this? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Bluetooth stack for FreeBSD (full status)
Hackers, Here is full status report on project i was working on. I apologize for the wide distribution, but i think that might be interesting. Bluetooth stack for FreeBSD (Netgraph implementation) = The project is making progress. I decided to submit report because now i have some confidence that i can make it actually work. The goal is to design and implement Host Controller Interface (HCI) and Link Layer Control and Adaptation Protocol (L2CAP) layers using Netgraph framework. All information obtained from Bluetooth Specification Book v1.1. More distant goal is to write support for Service Discovery Protocol (SDP) and RFCOMM protocol (serial port emulation over Bluetooth link). RFCOMM is more fun (IMO) and the current plan is to write RFCOMM Netgraph module and then tie it with ng_tty to complete the graph. BTW, while i was working on this Nokia has released another open source Bluetooth stack for Linux - Affix (http://affix.sourceforge.net). And i do not want to see FreeBSD behind :) Project roadmap Step 1: General design Status: Complete. Everything is pretty much defined and i have more or less clear picture of how it will work. However, there are several minor issues. I still trying to figure them out. Step 2: Implementation (HCI and L2CAP layer) Status: Complete. HCI and L2CAP Netgraph nodes have been implemented. Most of the implementation issues have been resolved. However, there are some parts of the code that may require minor changes. Step 3: Testing Status: In progress. I finally figured out how to etherboot -current under VMWare (would be nice if someone can put it into handbook), and now i have perfect sand box. Testing is likely to take some time. I do not have real Bluetooth hardware at this point, so i wrote some tools that allow me to test the code. Some of them will be used as foundation for future utilities. But i only can do spot testing. I need hardware. At this point the code seems to work, but i still need to test all failure modes and make sure code does the right thing. The Bluetooth specification does not provide great details on everything (IMO), so i'm trying to do reasonable thing. After this step is complete i will make an engineering release and make it available to the community. The purpose is to collect feedback from people who familiar with Netgraph and/or Bluetooth and make all required changes. Step 4: Utilities/Library API/Documentation Status: In progress. Some work already has been done as part of Step 3: Testing. I need some time and external input to figure out what is actually required. Ideal case would be to reuse what is already implemented. Step 5: Unit testing with real hardware Status: Not complete. I keep looking for Bluetooth hardware every day. I'm glad to see that it is actually exists. The good news is that some cards have UART 1650 on board, so (i hope) they are just fancy serial ports. If that is true, then ng_sio module would be perfect. The ng_sio will act just like ng_ether module, but for serial ports. NOTE: ng_sio module does not exist yet :) Step 6: Final acceptance testing and stable release Status: Not complete. This is not for me to decide :) I hope to get feedback from people. Issues == 1. Bluetooth hardware. I do not have real Bluetooth hardware and i need it badly :) If people can donate hardware/specs it would be great. I promise to write all required drivers and make them available. I also promise to return hardware/specs on first request. For now my plan is to spend some amount of $$$ and get a card or even two. 2. Project name. I would like to see the name that reflects the following: - it is a Bluetooth stack - implementation is for FreeBSD - implementation based on Netgraph framework Thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Bluetooth stack for FreeBSD (full status)
Duncan Barclay wrote: From: Terry Lambert [EMAIL PROTECTED] I haven't really taken an active interest in BlueTooth, since there are no laptops or printers that come with it already present; I rather think it will end up as still-born because of 802.11e Gigabit wireless, which can use as little or less power. There are now a few devices with Bluetooth in them. Sony has had a Viao with it in for a while. yes, Sony VAIO PCG-SR31K http://www.zdnet.co.uk/reviews/rstories/0,3040,e7110920,00.html as far as printing goes, you can get Bluetooth adapter for your printer. thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Audio burning problem with LG CED-8080B
Hackers, first of all i apologize for posting this in -hackers. it really belongs to -questions, but i saw similar messages in -questions and there was not much response. the problem is very simple: i can not burn audio CDs with my LG CED-8080B internal IDE drive and bunrcd. but here is a small detail: the drive _will_not_ burn audio track if next writable LBA _is_equal_ to zero :( however, if (and only if) next writable LBA _not_equal_ to zero, the drive _will_ burn audio track just fine. for now i have to put really small ISO image on the first track and then burn audio tracks :( some CD players get very upset because of this :( no such problem with data CDs. everything works just fine. please find attached file with more information. if somebody could explain what is going that would be great. thanks, max p.s. there is a similar PR in the database (http://www.freebsd.org/cgi/query-pr.cgi?pr=27893) # uname -a FreeBSD fly.private.org 4.4-STABLE FreeBSD 4.4-STABLE #0: Sun Oct 28 01:15:59 PDT 2001 [EMAIL PROTECTED]:/usr/src/sys/compile/FLY i386 # burncd -f /dev/acd0c -s 1 -t audio track1.cda fixate next writeable LBA 0 writing from file track1.cda size 269032 KB only wrote -1 of 37632 bytes fixating CD, please wait.. burncd: ioctl(CDRIOCCLOSEDISK): Input/output error # dmesg Copyright (c) 1992-2001 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 4.4-STABLE #0: Sun Oct 28 01:15:59 PDT 2001 [EMAIL PROTECTED]:/usr/src/sys/compile/FLY Calibrating clock(s) ... TSC clock: 400915491 Hz, i8254 clock: 1193201 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method CPU: Pentium II/Pentium II Xeon/Celeron (400.91-MHz 686-class CPU) Origin = GenuineIntel Id = 0x652 Stepping = 2 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 67108864 (65536K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x002cb000 - 0x03ff7fff, 64147456 bytes (15661 pages) avail memory = 62685184 (61216K bytes) bios32: Found BIOS32 Service Directory header at 0xc00fdad0 bios32: Entry = 0xfdae0 (c00fdae0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xdb01 pnpbios: Found PnP BIOS data at 0xc00f7700 pnpbios: Entry = f:6f1e Rev = 1.0 Other BIOS signatures found: ACPI: Preloaded elf kernel kernel at 0xc02a4000. Pentium Pro MTRR support enabled pci_open(1):mode 1 addr port (0x0cf8) is 0x8084 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=162110b9) Using $PIR table, 6 entries at 0xc00f7e20 npx0: math processor on motherboard npx0: INT 16 interface pcib0: Host to PCI bridge on motherboard found- vendor=0x10b9, dev=0x1621, revid=0x05 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[10]: type 1, range 32, base e000, size 26 found- vendor=0x10b9, dev=0x5247, revid=0x01 class=06-04-00, hdrtype=0x01, mfdev=0 subordinatebus=1secondarybus=1 found- vendor=0x10b9, dev=0x1533, revid=0xb4 class=06-01-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 found- vendor=0x100b, dev=0x0020, revid=0x00 class=02-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=7 map[10]: type 1, range 32, base dc00, size 8 map[14]: type 1, range 32, base dfffe000, size 12 found- vendor=0x10b9, dev=0x5229, revid=0x20 class=01-01-fa, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=0 map[20]: type 1, range 32, base ffa0, size 4 found- vendor=0x1317, dev=0x0985, revid=0x11 class=02-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=9 map[10]: type 1, range 32, base de00, size 8 map[14]: type 1, range 32, base dc00, size 10 pci0: PCI bus on pcib0 pcib1: AcerLabs M5247 PCI-PCI(AGP Supported) bridge at device 1.0 on pci0 found- vendor=0x1002, dev=0x475a, revid=0x3a class=03-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=0 map[10]: type 1, range 32, base de00, size 24 map[14]: type 1, range 32, base cc00, size 8 map[18]: type 1, range 32, base dfeff000, size 12 pci1: PCI bus on pcib1 pci1: ATI Mach64-GZ graphics accelerator (vendor=0x1002, dev=0x475a) at 0.0 irq 0 isab0: AcerLabs M1533 portable PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 sis0: NatSemi DP83815 10/100BaseTX port 0xdc00-0xdcff mem 0xdfffe000-0xdfffefff irq 7 at device 14.0 on pci0 sis0: Ethernet address: 00:02:e3:22:2f:28 miibus0: MII bus
Re: bluetooth
Duncan I might be worth talking to the people at http://www.blueaid.com/ Thanks for the info! Bill Munday has written and architected a number of the Bluetooth stacks various vendors use. He does free consulting and knows a _lot_ of people in the Bluetooth world. He is likely to know about other Bluetooth efforts for Linux. Again thanks for the name :) As far as Linux concern, i'm aware of two BlueTooth stacks for Linux 1) AXIS OpenBT stack (http://sourceforge.net/projects/openbt/) 2) Bluez (http://bluez.sourceforge.net/) (i actually know the Bluez author. Great programmer, we use to work together.) I can also help out with concepts/overviews etc. I have designed RFICs for Bluetooth and am part of the SIG writing version 1.2 of the standard (and no, I didn't do any of version 1.1 so don't hassle me!). Well, i would like to take this opportunity and tell a little bit more about current status :) If anyone feels that it is not appropriate place or time please let me know. [...] the implementation is based on Netgraph and supposed to be completely optional. The current design goals are: 1) Minimal changes to FreeBSD kernel code. It should be possible to maintain stack outside of FreeBSD code if required. 2) Stack must be optional. Do not want it - do not use it. 3) Stack must be flexible. Parts of the stack must be replaceable. 4) Stack must provide access to all protocol layers. 5) Try to avoid (if possible) kernel threads and try to reduce or eliminate extra overhead on synchronization. 6) Stack must provide option to configure each unit in special way to work around possible hardware bugs. 7) Try to stay within Netgraph infrastructure and reuse most of Netgraph tools (ngctl etc). i want to do something different rather than classic network stack. That is why i decided to try Netgraph framework. It is highly experimental code (proof of concept, if you will :) So far things looks like this. Please note i'm still working on this and there might be other oopes and gotchas :) x x | | User space /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ | | Kernel / | sco | acl \ +--V-V--+ / | | cmd \ | Netgraph HCI node ---/-- btd | | \daemon. +--^+ / Controls BlueTooth | drv\ unit | | | right Kernel space / User space +--V+ \ | |---/-- | Netgraph tee node | righ2left\btdump | |---/-- utility +--^+ left2right \ Dumps all packets | left / a-la tcpdump | | | hook +--V+ | | | BlueTooth unit driver | | (Netgraph node) | | | +---+ New instance of a HCI node are created for each BlueTooth unit. The participating nodes are connected as described above. The HCI node exports three hooks: 1) acl - ACL data (Data) 2) sco - SCO data (Voice) 3) cmd - special hook that allows to send HCI commands to the unit. All HCI commands and events are mapped to Netgraph control messages. One HCI command/event - one control message. The tee node is used to provide access to raw data and if this is not required may be omitted. The current model is one user space process per BlueTooth unit. However it might be converted to thread per process model. Control daemon btd is responsible for initialization and control of the unit. When daemon starts it sends set of HCI commands to recognize unit and then sends another set of HCI commands to perform actual intialization. Results are reported back in form of Netgraph control messages. The initialization sequence may vary depending on specific unit (to work around possible hardware bugs) and daemon must decide if it was successful or not. The control daemon also may implement additional features such as management of pin codes and link keys etc. In the near future there will be L2CAP node that will be attached to acl hook. But for now it is possible to implement L2CAP procotol as user space daemon, and then convert it to Netgraph node. The same is true for RFCOMM, SDP and TCP (Telephony Control Protocol :) nodes. thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: bluetooth
Is anyone working on bluetooth drivers and accompanying userland programs (bluetooth equivalents of wicontrol, etc.) ? ok :) i'm actually working on BlueTooth stack for FreeBSD. so far i have some code that implements basic functionality for HCI layer. the implementation is based on Netgraph and supposed to be completely optional. thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Netgraph feature request/suggestion
Hackers, i'm in the middle of the project that uses Netgraph. everything is going pretty good, but there is one small issue. in five words it is message and data delivery scheduling. here is an example: Node A -- Node B -- Node C Node A forwards data/messages to Node B and Node B in its turn forwards data/messages to Node C. the issue is that Node C can handle only some small amount of data/messages at a time. Node B is aware of Node C's limitation and must perform leaking bucket type of scheduling. i.e. Node B must queue data inside itself and then schedule later delivery to Node C. but that is not all. sometimes it is required to send chunk of data (several messages) from Node A to Node C. (via Node B) and until this chunk of data is processed by Node C, Node B is not allowed to send/accept any more data. i know about kernel threads and task queue, but i would really like to stay within Netgraph infrastructure and do not perform any extra synchronization. here is the proposal. every hook has two extra methods hk_RcvDataShed and hk_RcvmMgSched that performs scheduling. Node can turn on delivery scheduling on one of its hook by setting these methods. before actual data/message delivery Netgraph will call these methods and ask destination node is that a good time to deliver this data/message. if it is then delivery is performed. otherwise depending on HK_QUEUE bit data/message gets queued or dropped. or perhaps turning on delivery scheduling must turn on HK_QUEUE bit automatically. thanks, max p.s. i think it should be easy to implement, if people are interested. i can prepare the patches. p.p.s. if anyone knows nice solution to this problem please let me know. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Netgraph feature request/suggestion
Julian, [...] All this changes in -current where netraph was largely rewritten. i know. i'm using current i'm in the middle of the project that uses Netgraph. everything is going pretty good, but there is one small issue. in five words it is message and data delivery scheduling. here is an example: Node A -- Node B -- Node C Node A forwards data/messages to Node B and Node B in its turn forwards data/messages to Node C. the issue is that Node C can handle only some small amount of data/messages at a time. Node B is aware of Node C's limitation and must perform leaking bucket type of scheduling. i.e. Node B must queue data inside itself and then schedule later delivery to Node C. ok.. but that is not all. sometimes it is required to send chunk of data (several messages) from Node A to Node C. (via Node B) and until this chunk of data is processed by Node C, Node B is not allowed to send/accept any more data. yes, but I'l not sure what the problem is (Do you want C to notify B that it has room?) yes. Node C sends periodic notification to Node B. the easy solution here is to send one data/message at a time and wait until C sends notification back or timeout occur, then B will schedule another delivery (if any). but it kills the performance. and, like i said before, sometimes i just need to send chunk of data and wait for notification from C or for timeout. and in the same time i do not want keep A waiting. [] here is the proposal. every hook has two extra methods hk_RcvDataShed and hk_RcvmMgSched that performs scheduling. Hooks have no methods at this time, but, yes we can add them should you be very convincing :-) perhaps i should have used another word. -current Netgraph ng_hook structure has hk_rcvmsg and hk_rcvdata function pointers and node can set different message/data receive function per hook. suggestion was to add two more function pointers. i called them methods. Node can turn on delivery scheduling on one of its hook by setting these methods. before actual data/message delivery Netgraph will call these methods and ask destination node is that a good time to deliver this data/message. if it is then delivery is performed. otherwise depending on HK_QUEUE bit data/message gets queued or dropped. or perhaps turning on delivery scheduling must turn on HK_QUEUE bit automatically. The node can presently turn on the HK_QUEUE bit itself, but that will only delay the data for a short time.. It seesm to be that C needs to do it's own internal queueing. there can be multiply instances of C. i do not want to duplicate this code in every C instance. Is C an device driver? how does it get to run asynchronously? it could be a device driver, or it could be another node. it does not really matter (i think). and, yes, it does run asynchronously. that is why i do not want to mess around threads and task queues. extra overhead of locking etc. [...] Well in -current you could do it by locking the node C to serialise all accesses to it. You could also use the flow control messages defined in -current netgraph, to disable or re-enable data flow from A. hmmm... i should look into it. can you give me more information to help me understand the problem a bit better. i hope this helps, thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Proposed Utility - detach(1)
Chris Costello wrote: On Friday, August 24, 2001, Mike Barcroft wrote: I would appreciate comments on the usefulness of a utility which would allow one to detach a process from a TTY. I imagine the utility would be very small and just call daemon(3) and execlp(3). Would a utility like this be useful? Is this functionality already available in a system utility? All shells implement this: sh: $ sleep 5 $ [1] 61049 Exit 0 sleep 5 ksh: $ sleep 5 [1] 61052 $ [1] + Donesleep 5 csh: % sleep 5 [1] 61058 % [1]Done sleep 5 etc. Why does this need to be implemented in a separate executable? what you probably want to do is: % nohup sleep 5 to make sure that proccess is still alive if you logout. thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Pseudo ethernet interface
Is it possible to provide pseudo ethernet interfaces? Can we associate an IP and MAC address with a psuedo ethernet interface to facilitate data packet transmission reception through that? yes. If so, how does it work? Pointers to any documentation in this regard will be appreciated. $ man tap $ man ng_ether Have you looked at the tun device? this is IP only. thanks, emax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
[PATCH] Please review and commit (Re: if_tap and devfs)
Hello All, anyone wants to review and commit the following patch. thanks, emax __ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one Place. http://shopping.yahoo.com/ if_tap.c.diff
[PATCH] Please review and commit (Re: if_tap and devfs)
Hello Harti,
is there somebody working to make if_tap devfs-ready? Or I'm doing
something wrong?
[SNIP]
it seems to me that it did not get commited. i will look into it again
today and re-send patch to the list.
Great! It works. (Minus a spelling error: the parameter in
tapclone() should spell 'namelen'). Would nice if it get's committed.
ooops :) sorry about that. unfortunately, i can not commit it. we have
to ask one of the commiters.
To ALL:
anyone wants to review and commit the attached patch?
thanks,
emax
*** if_tap.c.orig Mon Nov 6 09:24:08 2000
--- if_tap.cMon Nov 6 10:26:35 2000
***
*** 79,84
--- 79,85
static inttapmodevent __P((module_t, int, void *));
/* device */
+ static void tapclone__P((void *, char *, int, dev_t *));
static void tapcreate __P((dev_t));
/* network interface */
***
*** 131,157
int type;
void*data;
{
! static int attached = 0;
! struct ifnet*ifp = NULL;
! int unit, s;
switch (type) {
case MOD_LOAD:
if (attached)
return (EEXIST);
cdevsw_add(tap_cdevsw);
attached = 1;
break;
! case MOD_UNLOAD:
if (taprefcnt 0)
return (EBUSY);
cdevsw_remove(tap_cdevsw);
unit = 0;
while (unit = taplastunit) {
s = splimp();
TAILQ_FOREACH(ifp, ifnet, if_link)
if ((strcmp(ifp-if_name, TAP) == 0) ||
--- 132,164
int type;
void*data;
{
! static int attached = 0;
! static eventhandler_tag eh_tag = NULL;
switch (type) {
case MOD_LOAD:
if (attached)
return (EEXIST);
+ eh_tag = EVENTHANDLER_REGISTER(dev_clone, tapclone, 0, 1000);
cdevsw_add(tap_cdevsw);
attached = 1;
break;
! case MOD_UNLOAD: {
! int unit;
!
if (taprefcnt 0)
return (EBUSY);
+ EVENTHANDLER_DEREGISTER(dev_clone, eh_tag);
cdevsw_remove(tap_cdevsw);
unit = 0;
while (unit = taplastunit) {
+ int s;
+ struct ifnet*ifp = NULL;
+
s = splimp();
TAILQ_FOREACH(ifp, ifnet, if_link)
if ((strcmp(ifp-if_name, TAP) == 0) ||
***
*** 179,185
}
attached = 0;
! break;
default:
return (EOPNOTSUPP);
--- 186,192
}
attached = 0;
! } break;
default:
return (EOPNOTSUPP);
***
*** 187,192
--- 194,234
return (0);
} /* tapmodevent */
+
+
+ /*
+ * DEVFS handler
+ *
+ * We need to support two kind of devices - tap and vmnet
+ */
+ static void
+ tapclone(arg, name, namelen, dev)
+ void*arg;
+ char*name;
+ int namelen;
+ dev_t *dev;
+ {
+ int unit, minor;
+ char*device_name = NULL;
+
+ if (*dev != NODEV)
+ return;
+
+ device_name = TAP;
+ if (dev_stdclone(name, NULL, device_name, unit) != 1) {
+ device_name = VMNET;
+
+ if (dev_stdclone(name, NULL, device_name, unit) != 1)
+ return;
+
+ minor = (unit | VMNET_DEV_MASK);
+ }
+ else
+ minor = unit;
+
+ *dev = make_dev(tap_cdevsw, minor, UID_ROOT, GID_WHEEL, 0600, "%s%d",
+ device_name, unit);
+ } /* tapclone */
/*
[PATCH] Re: if_tap and devfs
Hello,
I recently moved to using devfs and now if_tap seems unusable. Although
the module is loaded, it doesn't show up in /dev or as an interface.
From a quick comparison with if_tun it seems that this is 'expected'
behaviour although I'm not a specialist with devfs. Is this so? If yes,
is there somebody working to make if_tap devfs-ready? Or I'm doing
something wrong?
please try the following patch. it is not tested, sorry i dont have
FreeBSD box available right now :( please let me know the results.
thanks,
emax
*** if_tap.c.orig Mon Nov 6 09:24:08 2000
--- if_tap.cMon Nov 6 10:26:35 2000
***
*** 79,84
--- 79,85
static inttapmodevent __P((module_t, int, void *));
/* device */
+ static void tapclone__P((void *, char *, int, dev_t
*));
static void tapcreate __P((dev_t));
/* network interface */
***
*** 131,157
int type;
void*data;
{
! static int attached = 0;
! struct ifnet*ifp = NULL;
! int unit, s;
switch (type) {
case MOD_LOAD:
if (attached)
return (EEXIST);
cdevsw_add(tap_cdevsw);
attached = 1;
break;
! case MOD_UNLOAD:
if (taprefcnt 0)
return (EBUSY);
cdevsw_remove(tap_cdevsw);
unit = 0;
while (unit = taplastunit) {
s = splimp();
TAILQ_FOREACH(ifp, ifnet, if_link)
if ((strcmp(ifp-if_name, TAP) == 0) ||
--- 132,164
int type;
void*data;
{
! static int attached = 0;
! static eventhandler_tag eh_tag = NULL;
switch (type) {
case MOD_LOAD:
if (attached)
return (EEXIST);
+ eh_tag = EVENTHANDLER_REGISTER(dev_clone, tapclone, 0,
1000);
cdevsw_add(tap_cdevsw);
attached = 1;
break;
! case MOD_UNLOAD: {
! int unit;
!
if (taprefcnt 0)
return (EBUSY);
+ EVENTHANDLER_DEREGISTER(dev_clone, eh_tag);
cdevsw_remove(tap_cdevsw);
unit = 0;
while (unit = taplastunit) {
+ int s;
+ struct ifnet*ifp = NULL;
+
s = splimp();
TAILQ_FOREACH(ifp, ifnet, if_link)
if ((strcmp(ifp-if_name, TAP) == 0) ||
***
*** 179,185
}
attached = 0;
! break;
default:
return (EOPNOTSUPP);
--- 186,192
}
attached = 0;
! } break;
default:
return (EOPNOTSUPP);
***
*** 187,192
--- 194,234
return (0);
} /* tapmodevent */
+
+
+ /*
+ * DEVFS handler
+ *
+ * We need to support two kind of devices - tap and vmnet
+ */
+ static void
+ tapclone(arg, name, namlen, dev)
+ void*arg;
+ char*name;
+ int namelen;
+ dev_t *dev;
+ {
+ int unit, minor;
+ char*device_name = NULL;
+
+ if (*dev != NODEV)
+ return;
+
+ device_name = TAP;
+ if (dev_stdclone(name, NULL, device_name, unit) != 1) {
+ device_name = VMNET;
+
+ if (dev_stdclone(name, NULL, device_name, unit) != 1)
+ return;
+
+ minor = (unit | VMNET_DEV_MASK);
+ }
+ else
+ minor = unit;
+
+ *dev = make_dev(tap_cdevsw, minor, UID_ROOT, GID_WHEEL, 0600,
"%s%d",
+ device_name, unit);
+ } /* tapclone */
/*
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
NETGRAPH patches (proposal)
Hello All, Here are some small patches for NETGRAPH. These are against -current cvsup'ed yesterday around 8:30pm EST. http://home.earthlink.net/~evmax/ng.tar.gz It also includes small test program (based on nghook). Compile and run it like: # ./a.out -a iface_name: divert NETGRAPH option in kernel config file is required. Here is the description. ng_ether node has two hooks ``divert'' and ``orphan''. It is possible to connect to the one of the hooks and intercept row Ethernet frames. But there is no clean way to intercept frame, do something and return it back to kernel. This patch provides additional hook ``divertin'' (mmm... name is not good, i think) for each ng_ether node. Implementation issues This will not work for ``orphan'' frames. Since kernel drops it anyway, i decided to leave it as it is. But is is possible to intercept ``orphan'' packets, change it, and write back to ``divertin''. Thanks, emax __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
misc/12633: CMI8330 chip based integrated sound card produce no output
Hi, I have some minor probem with my CMI8330 chip based integrated sound card on m726 motherboard. Here's the URL where you can find how to fix it: http://www.cslab.vt.edu/~jobaldwi/cmi8330init.tar.gz = cut here = Thank you very much for your problem report. It has the internal identification `misc/12633'. The individual assigned to look at your report is: freebsd-bugs. Category: misc Responsible:freebsd-bugs Synopsis: CMI8330 chip based integrated sound card produce no output Arrival-Date: Tue Jul 13 15:30:01 PDT 1999 end === To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
misc/12633: CMI8330 chip based integrated sound card produce no output
Hi, I have some minor probem with my CMI8330 chip based integrated sound card on m726 motherboard. Here's the URL where you can find how to fix it: http://www.cslab.vt.edu/~jobaldwi/cmi8330init.tar.gz = cut here = Thank you very much for your problem report. It has the internal identification `misc/12633'. The individual assigned to look at your report is: freebsd-bugs. Category: misc Responsible:freebsd-bugs Synopsis: CMI8330 chip based integrated sound card produce no output Arrival-Date: Tue Jul 13 15:30:01 PDT 1999 end === To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
