Re: Something wrong with curs_threads(3X) ?
On 2012-05-21 18:41, Yanhui Shen wrote: > In curs_threads(3X), at the beginning of the manual: > > typedef int (*NCURSES_WINDOW_CB)(WINDOW *, void *); typedef int >>(*NCURSES_SCREEN_CB)(SCREEN *, void *); >>int set_escdelay(int size); >>int set_tabsize(int size); >>int use_screen(SCREEN *scr, NCURSES_WINDOW_CB func, void *data); >>int use_window(WINDOW *win, NCURSES_SCREEN_CB func, void *data); That's indeed a documentation error. Fixed in r235773, thanks! ___ 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: proper newfs options for SSD disk
El día Sunday, May 20, 2012 a las 03:36:01AM +0900, rozhuk...@gmail.com escribió: > > My EeePC netbook shows for the two SSD: > > > > $ uname -a > > FreeBSD tiny 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r226986: Tue Nov 1 > > 14:27:40 CET 2011 guru@caracas:/usr/obj/usr/src/sys/GENERIC i386 > > $ gpart show > > => 63 7880481 ada0 MBR (3.8G) > >63 7880481 1 freebsd [active] (3.8G) > > > > => 63 31522113 ada1 MBR (15G) > > 63 31522113 1 freebsd [active] (15G) > > > > => 0 7880481 ada0s1 BSD (3.8G) > > 0 16 - free - (8.0k) > >16 7880465 1 freebsd-ufs (3.8G) > > > > => 0 31522113 ada1s1 BSD (15G) > > 016 - free - (8.0k) > > 16 31522097 1 freebsd-ufs (15G) > > > > Do not use MBR (or manually do all to align). > 63 - not 4k aligned. Hi, To create the above shown partition layout I have not used gpart(8); I just said: # fdisk -I /dev/ada0 # fdisk -B /dev/ada0 # bsdlabel -w ada0s1 auto # bsdlabel -B ada0s1 changed partition "a" from "unused" to "4.2BSD" as partition type: # setenv EDITOR /usr/bin/vi # bsdlabel -e ada0s1 created the future root-filesystem on it # newfs -m 0 -o space /dev/ada0s1a The 2nd SSD was formated like this: # dd if=/dev/zero of=/dev/ada1 count=2 # fdisk -I /dev/ada1 # newfs -m 0 -o space /dev/ada1s1a # echo "/dev/ada1s1a /usr/local ufs rw,noatime 1 1" >> /etc/fstab # mount /usr/local What is wrong with this procedure? Thanks matthias -- Matthias Apitz e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 ___ 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: ARM + CACHE_LINE_SIZE + DMA
On Tuesday 22 May 2012 01:35:48 Alexander Kabaev wrote: > On Thu, 17 May 2012 11:01:34 -0500 > > Mark Tinguely wrote: > > On Thu, May 17, 2012 at 8:20 AM, Svatopluk Kraus > > > > wrote: > > > Hi, > > > > > > I'm working on DMA bus implementation for ARM11mpcore platform. I've > > > looked at implementation in ARM tree, but IMHO it only works with > > > some assumptions. There is a problem with DMA on memory block which > > > is not aligned on CACHE_LINE_SIZE (start and end) if memory is not > > > coherent. > > > > > > Let's have a buffer for DMA which is no aligned on CACHE_LINE_SIZE. > > > Then first cache line associated with the buffer can be divided into > > > two parts, A and B, where A is a memory we know nothing about it > > > and B is buffer memory. The same stands for last cache line > > > associatted with the buffer. We have no problem if a memory is > > > coherent. Otherwise it depends on memory attributes. > > > > > > 1. [no cache] attribute > > > No problem as memory is coherent. > > > > > > 2. [write throught] attribute > > > The part A can be invalidated without loss of any data. It's not > > > problem too. > > > > > > 3. [write back] attribute > > > In general, there is no way how to keep both parts consistent. At > > > the start of DMA transaction, the cache line is written back and > > > invalidated. However, as we know nothing about memory associated > > > with part A of the cache line, the cache line can be filled again > > > at any time and messing up DMA transaction if flushed. Even if the > > > cache line is only filled but not flushed during DMA transaction, > > > we must make it coherent with memory after that. There is a trick > > > with saving part A of the line into temporary buffer, invalidating > > > the line, and restoring part A in current ARM (MIPS) > > > implementation. However, if somebody is writting to memory > > > associated with part A of the line during this trick, the part A > > > will be messed up. Moreover, the part A can be part of another DMA > > > transaction. > > > > > > To safely use DMA with no coherent memory, a memory with [no cache] > > > or [write throught] attributes can be used without problem. A > > > memory with [write back] attribute must be aligned on > > > CACHE_LINE_SIZE. > > > > > > However, for example mbuf, a buffer for DMA can be part of a > > > structure which can be aligned on CACHE_LINE_SIZE, but not the > > > buffer itself. We can know that nobody will write to the structure > > > during DMA transaction, so it's safe to use the buffer event if > > > it's not aligned on CACHE_LINE_SIZE. > > > > > > So, in practice, if DMA buffer is not aligned on CACHE_LINE_SIZE and > > > we want to avoid bounce pages overhead, we must support additional > > > information to DMA transaction. It should be easy to support the > > > information about drivers data buffers. However, what about OS data > > > buffers like mentioned mbufs? > > > > > > The question is following. Is or can be guaranteed for all or at > > > least well-known OS data buffers which can be part of DMA access > > > that the not CACHE_LINE_SIZE aligned buffers are surrounded by data > > > which belongs to the same object as the buffer and the data is not > > > written by OS when given to a driver? > > > > > > Any answer is appreciated. However, 'bounce pages' is not an answer. > > > > > > Thanks, Svata > > > > Sigh. A several ideas by several people, but a good answer has not > > been created yet. SMP will make this worse. > > > > To make things worse, there are drivers that use memory from the > > stack as DMA buffers. > > > > I was hoping that mbufs are pretty well self-contained, unless you > > expect to modify them while DMA is happening. > > > > This is on my to-do list. > > > > --Mark. > > Drivers that do DMA from memory that was not allocated by proper busdma > methods or load buffers for DMA using not properly constrained busdma > tags are broken drivers. We did not have a busdma tag inheritance from > parent bus to child devices before, but now we should just take > advantage of that and just make cache line alignment a requirement for > the platform. USB is firmly in that 'broken' category btw and is > currently being worked around by the USB_HOST_ALIGN hack on MIPS, which > suffers from the very same cache coherency issues you describe. Hi, Drivers do not always use the same buffer format. That mean two entities exchanging data using different buffer allocations must either: 1) Copy the data 2) Negotiate parameters for zero copy Many USB protocols have headers which are designed without any thought about ARM's and CACHE alignment. That means byte access via DMA must be supported, else you end up having to copy the data en-mass. The USB_HOST_ALIGN is not a hack. It is coherently implemented across EHCI, OHCI, UHCI and XHCI drivers, which are currently the only USB drivers using DMA. BUSDMA must instruct use of bounce buffers for case 1) for such CP
Re: Need to revert behavior of OpenSSH to the old key order ...
On Mon, May 21, 2012 at 02:26:27PM -0700, Jason Usher wrote: > > > --- On Mon, 5/21/12, Garance A Drosehn wrote: > > > ???But have you tried it in this order ? > > > > ???HostKey /usr/local/etc/ssh/ssh_host_key > > ???HostKey > > /usr/local/etc/ssh/ssh_host_dsa_key > > ???HostKey > > /usr/local/etc/ssh/ssh_host_rsa_key > > ???HostKey > > /usr/local/etc/ssh/ssh_host_ecdsa_key > > > > Which is to say, have your sshd_config file list multiple > > hostkey's, and then restart sshd after making that change? > > I tried a similar change and it seemed to have some effect > > on what clients saw when connecting, but I can't tell if > > it has the effect that you want. > > > The order of HostKey directives in sshd_config does not change the actual > order. In newer implementations, RSA is provided first, no matter how you > configure the sshd_config. > > As I mentioned before, removing RSA completely is sort of a fix, but I can't > do that because some people might actually be explicitly using RSA, and they > would all break. > > Anyone ? The problem to me seems to be on the client end. Where the new ssh installation is attempting RSA authentication first rather than DSA and your ssh server has just now caught up to the clients. If I were you, I would just make an announcement providing the host fingerprints to clients and asking them to update known_hosts appropriately, rather than creating a virtual fix for sshd that you will have to maintain yourself. -- - (2^(N-1)) ___ 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: ARM + CACHE_LINE_SIZE + DMA
On Thu, 17 May 2012 11:01:34 -0500 Mark Tinguely wrote: > On Thu, May 17, 2012 at 8:20 AM, Svatopluk Kraus > wrote: > > Hi, > > > > I'm working on DMA bus implementation for ARM11mpcore platform. I've > > looked at implementation in ARM tree, but IMHO it only works with > > some assumptions. There is a problem with DMA on memory block which > > is not aligned on CACHE_LINE_SIZE (start and end) if memory is not > > coherent. > > > > Let's have a buffer for DMA which is no aligned on CACHE_LINE_SIZE. > > Then first cache line associated with the buffer can be divided into > > two parts, A and B, where A is a memory we know nothing about it > > and B is buffer memory. The same stands for last cache line > > associatted with the buffer. We have no problem if a memory is > > coherent. Otherwise it depends on memory attributes. > > > > 1. [no cache] attribute > > No problem as memory is coherent. > > > > 2. [write throught] attribute > > The part A can be invalidated without loss of any data. It's not > > problem too. > > > > 3. [write back] attribute > > In general, there is no way how to keep both parts consistent. At > > the start of DMA transaction, the cache line is written back and > > invalidated. However, as we know nothing about memory associated > > with part A of the cache line, the cache line can be filled again > > at any time and messing up DMA transaction if flushed. Even if the > > cache line is only filled but not flushed during DMA transaction, > > we must make it coherent with memory after that. There is a trick > > with saving part A of the line into temporary buffer, invalidating > > the line, and restoring part A in current ARM (MIPS) > > implementation. However, if somebody is writting to memory > > associated with part A of the line during this trick, the part A > > will be messed up. Moreover, the part A can be part of another DMA > > transaction. > > > > To safely use DMA with no coherent memory, a memory with [no cache] > > or [write throught] attributes can be used without problem. A > > memory with [write back] attribute must be aligned on > > CACHE_LINE_SIZE. > > > > However, for example mbuf, a buffer for DMA can be part of a > > structure which can be aligned on CACHE_LINE_SIZE, but not the > > buffer itself. We can know that nobody will write to the structure > > during DMA transaction, so it's safe to use the buffer event if > > it's not aligned on CACHE_LINE_SIZE. > > > > So, in practice, if DMA buffer is not aligned on CACHE_LINE_SIZE and > > we want to avoid bounce pages overhead, we must support additional > > information to DMA transaction. It should be easy to support the > > information about drivers data buffers. However, what about OS data > > buffers like mentioned mbufs? > > > > The question is following. Is or can be guaranteed for all or at > > least well-known OS data buffers which can be part of DMA access > > that the not CACHE_LINE_SIZE aligned buffers are surrounded by data > > which belongs to the same object as the buffer and the data is not > > written by OS when given to a driver? > > > > Any answer is appreciated. However, 'bounce pages' is not an answer. > > > > Thanks, Svata > > Sigh. A several ideas by several people, but a good answer has not > been created yet. SMP will make this worse. > > To make things worse, there are drivers that use memory from the > stack as DMA buffers. > > I was hoping that mbufs are pretty well self-contained, unless you > expect to modify them while DMA is happening. > > This is on my to-do list. > > --Mark. Drivers that do DMA from memory that was not allocated by proper busdma methods or load buffers for DMA using not properly constrained busdma tags are broken drivers. We did not have a busdma tag inheritance from parent bus to child devices before, but now we should just take advantage of that and just make cache line alignment a requirement for the platform. USB is firmly in that 'broken' category btw and is currently being worked around by the USB_HOST_ALIGN hack on MIPS, which suffers from the very same cache coherency issues you describe. -- Alexander Kabaev signature.asc Description: PGP signature
Re: Need to revert behavior of OpenSSH to the old key order ...
--- On Mon, 5/21/12, Garance A Drosehn wrote: > But have you tried it in this order ? > > HostKey /usr/local/etc/ssh/ssh_host_key > HostKey > /usr/local/etc/ssh/ssh_host_dsa_key > HostKey > /usr/local/etc/ssh/ssh_host_rsa_key > HostKey > /usr/local/etc/ssh/ssh_host_ecdsa_key > > Which is to say, have your sshd_config file list multiple > hostkey's, and then restart sshd after making that change? > I tried a similar change and it seemed to have some effect > on what clients saw when connecting, but I can't tell if > it has the effect that you want. The order of HostKey directives in sshd_config does not change the actual order. In newer implementations, RSA is provided first, no matter how you configure the sshd_config. As I mentioned before, removing RSA completely is sort of a fix, but I can't do that because some people might actually be explicitly using RSA, and they would all break. Anyone ? ___ 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: Review of changes for getnetgrent.c
On May 21, 2012, at 2:29 PM, Xin Li wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 05/21/12 12:02, Guy Helmer wrote:
>>
>> On May 18, 2012, at 6:09 PM, Xin Li wrote:
>>
>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>>
>>> On 05/18/12 14:58, Guy Helmer wrote:
To close PR bin/83340, I have this change worked up to resolve
memory allocation failure handling and avoid creating bad
entries in the grp list due to memory allocation failures while
building a new entry.
Before committing, I wanted to run it past others to see if
there were any problems with it.
>>>
>>> %%% @@ -477,6 +475,13 @@ if (len > 0) { grp->ng_str[strpos] =
>>> (char *) malloc(len + 1); + if
>>> (grp->ng_str[strpos] == NULL)
>>> { + for (freepos = 0;
>>> freepos < strpos; freepos++) +
>>> if (grp->ng_str[freepos] != NULL) +
>>> free(grp->ng_str[freepos]); +
>>> free(grp); +
>>> return(1); +} bcopy(spos,
>>> grp->ng_str[strpos], len + 1);
>>> %%%
>>
>> Like this?
>>
>> if (len > 0) { grp->ng_str[strpos] = (char *) malloc(len + 1); +
>> if (grp->ng_str[strpos] == NULL) { +
>> int freepos; + for
>> (freepos = 0; freepos < strpos; freepos++) +
>> free(grp->ng_str[freepos]); +
>> free(grp); +
>> return(1); +
>> } bcopy(spos, grp->ng_str[strpos], len + 1); }
>>>
>>> There are a few return without space between the keyword and
>>> return value.
>>
>> Do you recommend I fix all those instances in the file, or just the
>> instances in this patch?
>
> I'd recommend fixing them all (note that you could run into a bigger
> commit as the switch() is not style(9) conformant at this time) and we
> normally do it in two different commits (one style, and another
> functional) when possible.
>
OK, thank you.
Guy
This message has been scanned by ComplianceSafe, powered by Palisade's
PacketSure.
___
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: PID/UID namespaces
On 21 May 2012 20:57, Poul-Henning Kamp wrote: > In message > > , Chris Rees writes: > >>It would certainly prevent many common problems when setting up jails; >>UID collision is much more common than you'd think, given that the >>default UIDs remain the same. > > Uhm... jails have separate UID/GID spaces. > > Filesystems mounted or visible in multiple jails act as shared UID/GID > (sub-)spaces for those jails, but there is now way to avoid that, it's > a direct consequence of the sharing of the filesystems. Yes, beg pardon, my mistake-- that's what I was meaning to refer to. I still have a patch in GNATS for the docs about that, but it's been the subject of amazing controversy. Chris ___ 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: PID/UID namespaces
In message , Chris Rees writes: >It would certainly prevent many common problems when setting up jails; >UID collision is much more common than you'd think, given that the >default UIDs remain the same. Uhm... jails have separate UID/GID spaces. Filesystems mounted or visible in multiple jails act as shared UID/GID (sub-)spaces for those jails, but there is now way to avoid that, it's a direct consequence of the sharing of the filesystems. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: Review of changes for getnetgrent.c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/21/12 12:02, Guy Helmer wrote:
>
> On May 18, 2012, at 6:09 PM, Xin Li wrote:
>
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>
>> On 05/18/12 14:58, Guy Helmer wrote:
>>> To close PR bin/83340, I have this change worked up to resolve
>>> memory allocation failure handling and avoid creating bad
>>> entries in the grp list due to memory allocation failures while
>>> building a new entry.
>>>
>>> Before committing, I wanted to run it past others to see if
>>> there were any problems with it.
>>
>> %%% @@ -477,6 +475,13 @@ if (len > 0) { grp->ng_str[strpos] =
>> (char *) malloc(len + 1); + if
>> (grp->ng_str[strpos] == NULL)
>> { + for (freepos = 0;
>> freepos < strpos; freepos++) +
>> if (grp->ng_str[freepos] != NULL) +
>> free(grp->ng_str[freepos]); +
>> free(grp); +
>> return(1); + } bcopy(spos,
>> grp->ng_str[strpos], len + 1);
>> %%%
>
> Like this?
>
> if (len > 0) { grp->ng_str[strpos] = (char *) malloc(len + 1); +
> if (grp->ng_str[strpos] == NULL) { +
> int freepos; + for
> (freepos = 0; freepos < strpos; freepos++) +
> free(grp->ng_str[freepos]); +
> free(grp); +return(1); +
> } bcopy(spos, grp->ng_str[strpos], len + 1); }
>>
>> There are a few return without space between the keyword and
>> return value.
>
> Do you recommend I fix all those instances in the file, or just the
> instances in this patch?
I'd recommend fixing them all (note that you could run into a bigger
commit as the switch() is not style(9) conformant at this time) and we
normally do it in two different commits (one style, and another
functional) when possible.
Cheers,
- --
Xin LI https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (FreeBSD)
iQEcBAEBCAAGBQJPupePAAoJEG80Jeu8UPuz52wH/RVJXpCyea+ep08XDx82D7tG
us+ujKa1aNOUumzwJRsJ4SNVBiyc+hqCtb8s7FjjeF4/SJk8oei/I1/M1JIyMuIh
FawSB8rNJCbn/u9Od19iOeh/f/IDeCN+q8OrUK5mqQ7G1KDcHs12h86AFlm9HA7K
8UyxneTkPfKhED6hkgSll6bqYAJLeR5jJ3CCGvBeXxNgzJyyAhICWv0UgzUpcY9d
l2beuIXc57toDaLrbWkooLfQclDWPWyyPXq7okexQAq8OUjqmQFE+EhcYsIbtBkH
uBW67jhH81MZf/Ryl83VeqT9IChOySAU0YiwOQxaxdlqR53VAenAY0sWS1QvuX8=
=drgy
-END PGP SIGNATURE-
___
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: ARM + CACHE_LINE_SIZE + DMA
On Mon, May 21, 2012 at 11:20 AM, Ian Lepore wrote: > On Fri, 2012-05-18 at 16:13 +0200, Svatopluk Kraus wrote: >> On Thu, May 17, 2012 at 10:07 PM, Ian Lepore >> wrote: >> > On Thu, 2012-05-17 at 15:20 +0200, Svatopluk Kraus wrote: >> >> Hi, >> >> >> >> I'm working on DMA bus implementation for ARM11mpcore platform. I've >> >> looked at implementation in ARM tree, but IMHO it only works with some >> >> assumptions. There is a problem with DMA on memory block which is not >> >> aligned on CACHE_LINE_SIZE (start and end) if memory is not coherent. >> >> >> >> Let's have a buffer for DMA which is no aligned on CACHE_LINE_SIZE. >> >> Then first cache line associated with the buffer can be divided into >> >> two parts, A and B, where A is a memory we know nothing about it and B >> >> is buffer memory. The same stands for last cache line associatted with >> >> the buffer. We have no problem if a memory is coherent. Otherwise it >> >> depends on memory attributes. ... > My suggestion of making a temporary writable mapping was the answer to > how to correctly change memory attributes on a page which is in use, at > least in the existing code, which is for a single processor. > > You don't need, and won't even use, the temporary mapping. You would > make it just because doing so invokes logic in arm/arm/pmap.c which will > find all existing virtual mappings of the given physical pages, and > disable caching in each of those existing mappings. In effect, it makes > all existing mappings of the physical pages DMA_COHERENT. When you > later free the temporary mapping, all other existing mappings are > changed back to being cacheable (as long as no more than one of the > mappings that remain is writable). > > I don't know that making a temporary mapping just for its side effect of > changing other existing mappings is a good idea, it's just a quick and > easy thing to do if you want to try changing all existing mappings to > non-cacheable. It could be that a better way would be to have the > busdma_machdep code call directly to lower-level routines in pmap.c to > change existing mappings without making a new temporary mapping in the > kernel pmap. The actual changes to the existing mappings are made by > pmap_fix_cache() but that routine isn't directly callable right now. > > Also, as far as I know all of this automatic disabling of cache for > multiple writable mappings applies only to VIVT cache architectures. > I'm not sure how the pmap code is going to change to support VIPT and > PIPT caches, but it may no longer be true that making a second writable > mapping of a page will lead to changing all existing mappings to > non-cacheable. > > -- Ian We don't want to carry the VIVT cache fixing code to VIPT/PIPT. I like the x86 approach of marking the page with a cache type (default/device/uncached/etc). The page mapping routines (for example pmap_qenter() on a clustered write) will honor that cache type in all future mappings. It is easy to implement. Other allocations, such as page tables, can benefit from an attributed allocation too. I also like having a separate allocator for the sub-page bus_dmamem_alloc() requests that want uncached buffers. These entries can stick around for a long time. If we just malloced the entries, then the other threads that happen to allocate data from the same page are penalized with uncached buffers too. --Mark. ___ 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: PID/UID namespaces
On 21 May 2012 14:47, David Windsor wrote: > Hi, > > While doing some research on FreeBSD jails, I came across an item in the > jails' TODO: > > > - be able to have a separate PID space for it > - be able to specify a separate UID space for it > > In other projects, these goals have been accomplished using namespaces. I > tried to see if PID/UID namespaces existed in BSD and came across something > called Capsicum, a sandboxing project which does not appear to implement > outright namespaces for descriptors like PID/UID, but uses something called > a "Process Descriptor." > > Is namespacing of PIDs and UIDs an eventual goal of the jails project of > FreeBSD? It would certainly prevent many common problems when setting up jails; UID collision is much more common than you'd think, given that the default UIDs remain the same. Chris ___ 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: PID/UID namespaces
On 5/21/12 6:47 AM, David Windsor wrote: Hi, While doing some research on FreeBSD jails, I came across an item in the jails' TODO: - be able to have a separate PID space for it - be able to specify a separate UID space for it In other projects, these goals have been accomplished using namespaces. I tried to see if PID/UID namespaces existed in BSD and came across something called Capsicum, a sandboxing project which does not appear to implement outright namespaces for descriptors like PID/UID, but uses something called a "Process Descriptor." Is namespacing of PIDs and UIDs an eventual goal of the jails project of FreeBSD? "kinda" Note terribly explicitly, but somewhere in our collective subconscious.. Thanks, David PS: Excuse my ignorance of anything related to BSD, as I come from a Linux background. ___ 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: Review of changes for getnetgrent.c
On May 18, 2012, at 6:09 PM, Xin Li wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 05/18/12 14:58, Guy Helmer wrote:
>> To close PR bin/83340, I have this change worked up to resolve
>> memory allocation failure handling and avoid creating bad entries
>> in the grp list due to memory allocation failures while building a
>> new entry.
>>
>> Before committing, I wanted to run it past others to see if there
>> were any problems with it.
>
> %%%
> @@ -477,6 +475,13 @@
> if (len > 0) {
> grp->ng_str[strpos] = (char *)
> malloc(len + 1);
> + if (grp->ng_str[strpos] ==
> NULL) {
> + for (freepos = 0;
> freepos < strpos; freepos++)
> + if
> (grp->ng_str[freepos] != NULL)
> +
> free(grp->ng_str[freepos]);
> + free(grp);
> + return(1);
> + }
> bcopy(spos, grp->ng_str[strpos],
> len + 1);
> %%%
Like this?
if (len > 0) {
grp->ng_str[strpos] = (char *)
malloc(len + 1);
+ if (grp->ng_str[strpos] ==
NULL) {
+ int freepos;
+ for (freepos = 0;
freepos < strpos; freepos++)
+
free(grp->ng_str[freepos]);
+ free(grp);
+ return(1);
+ }
bcopy(spos, grp->ng_str[strpos],
len + 1);
}
>
> There are a few return without space between the keyword and return value.
Do you recommend I fix all those instances in the file, or just the instances
in this patch?
Thanks,
Guy
This message has been scanned by ComplianceSafe, powered by Palisade's
PacketSure.
___
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: Need to revert behavior of OpenSSH to the old key order ...
I may have missed some emails in this thread, but did you try this suggestion: But have you tried it in this order ? HostKey /usr/local/etc/ssh/ssh_host_key HostKey /usr/local/etc/ssh/ssh_host_dsa_key HostKey /usr/local/etc/ssh/ssh_host_rsa_key HostKey /usr/local/etc/ssh/ssh_host_ecdsa_key Which is to say, have your sshd_config file list multiple hostkey's, and then restart sshd after making that change? I tried a similar change and it seemed to have some effect on what clients saw when connecting, but I can't tell if it has the effect that you want. -- garance On 5/21/12 12:18 PM, Jason Usher wrote: Folks, Is there a better list for this - perhaps freebsd-security ? I originally posted to -hackers because it *appears* that reverting "rsa, then dsa" to "dsa, then rsa" was a simple change to myproposal.h, but since that doesn't work, and since I haven't gotten any replies here ... Thoughts ? ___ 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: ARM + CACHE_LINE_SIZE + DMA
Hi Ian (and list), just commenting on the mbuf part : On Monday 21 May 2012 18:20:21 Ian Lepore wrote: > On Fri, 2012-05-18 at 16:13 +0200, Svatopluk Kraus wrote: > > On Thu, May 17, 2012 at 10:07 PM, Ian Lepore > > wrote: > > > On Thu, 2012-05-17 at 15:20 +0200, Svatopluk Kraus wrote: > > >> Hi, ... > > What I can do in a driver it's not so simple in case of OS buffers > > like mbufs. I can check how mbufs are used in current implementation > > and say, yes, it's safe to use them unaligned. However, it can be > > changed in next release if anybody won't take care of it. It would be > > nice to have a maintained list of OS buffers which are DMA safe in > > respect of CACHE_LINE_SIZE. Is the flag and the list interesting for > > somebody else? > > I don't have a definitive answer for this, but my assumption has always > been that once an mbuf is handed to a driver (for example, when it's > added to an interface's send queue), the driver then "owns" that mbuf > and nothing else in the system will touch it until the driver makes a > call to hand it off or free it. If that assumption is true, a driver > could make good use of a BUS_DMA_UNALIGNED_SAFE flag with mbufs. > > The part that scares me about my assumption is the m_ext.ref_cnt field > of the mbuf. Its existance seems to imply that multiple entities > concurrently have an interest in the data. On the other hand, the lack > of any built in provisions for locking seems to imply that concurrent > access isn't happening, or perhaps it implies that any required > synchronization is temporal rather than lock-based. > > I've never found anything in writing that explains mbuf usage > conventions at this level of detail. This assumption isn't always true. 'man 9 mbuf' mentions this, but not in one place. M_WRITABLE() can be used to tell wether or not you're allowed to modify an mbuf. If it returns false, you can create a writable copy of the mbuf and alter the copy instead of the original. A writable copy of an mbuf can be made using m_dup(). Writing to non-writable mbuf's will cause data corruption in e.g. BPF and TCP retransmits (even in the non-SMP case). Regards, -- Daan Vreeken Vitsch Electronics http://Vitsch.nl tel: +31-(0)40-7113051 KvK nr: 17174380 ___ 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: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On Mon, 21 May 2012 12:01:19 -0500, Andrew Boyer wrote: You could try switching mpt to MSI. MSI interrupts are never shared. Add this to /boot/device.hints: hint.mpt.0.msi_enable="1" Currently implementing this on the known crashy servers. I've been looking around and all of our VM's that do NOT crash also do not share interrupts between em0/mpt0. Thank you very much if this is the fix we will be SO grateful. ___ 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"
We invite you to a remote job $ 100 per hour helping sick people
We invite you to work in the remote assistant position. This work takes 2-3 hours per week and requires absolutely no investment. The essence of this work for incoming client requests in your city. The starting salary is about 2500 EUR per month + bonuses. You get paid your salary every 2 weeks and your bonuses after fulfilling each task! We guarantee work for everyone. But we accept applications this week only! Therefore, you should write a request right now. And you will start earning money, starting from next week. Please indicate in the request: Your name: Your email address: City of residence: Please send the request to my email col...@topeuropajobs.com,and I will answer you personally as soon as possible Sincerely, Collin Burns ___ 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: Need to revert behavior of OpenSSH to the old key order ...
On Mon, May 21, 2012 at 09:18:32AM -0700, Jason Usher wrote: > > Folks, > > Is there a better list for this - perhaps freebsd-security ? > > I originally posted to -hackers because it *appears* that reverting "rsa, > then dsa" to "dsa, then rsa" was a simple change to myproposal.h, but since > that doesn't work, and since I haven't gotten any replies here ... > > Thoughts ? OpenBSD ? http://www.openssh.org/list.html > > > --- On Thu, 5/17/12, Jason Hellenthal wrote: > > > > > > I have some old 6.x FreeBSD systems that need > > their > > > > OpenSSH upgraded. > > > > > > > > > > Everything goes just fine, but when I am > > done, existing > > > > clients are now presented with this message: > > > > > > > > > > > > > > > WARNING: DSA key found for host hostname > > > > > in /root/.ssh/known_hosts:12 > > > > > DSA key fingerprint > > 4c:29:4b:6e:b8:6b:fa:49... > > > > > > > > > > The authenticity of host 'hostname > > (10.1.2.3)' can't be > > > > established > > > > > but keys of different type are already known > > for this > > > > host. > > > > > RSA key fingerprint is > > a3:22:3d:cf:f2:46:09:f2.. > > > > > Are you sure you want to continue connecting > > (yes/no) > > > > > > > > > > > > > You must be using different keys for your server > > than the > > > > one that has > > > > been generated before the upgrade. Just copy your > > keys over > > > > to the new > > > > location and restart the server daemon and you > > should be > > > > fine. > > > > > > > > copy /etc/ssh/* -> /usr/local/etc/ssh/ > > > > > > > > > You didn't read that error message. > > > > Sorry I misread that. Decieving message... > > > > > > > > That is not the standard "key mismatch" error that you > > assumed it was. Look at it again - it is saying that > > we do have a key for this server of type DSA, but the client > > is receiving one of type RSA, etc. > > > > > > The keys are the same - they have not changed at all - > > they are just being presented to clients in the reverse > > order, which is confusing them and breaking automated, > > key-based login. > > > > > > I need to take current ssh server behavior (rsa, then > > dss) and change it back to the old order (dss, then rsa). > > > > Have you attempted to change that order via sshd_config and > > placing the > > DSA directive before the RSA one ? > > > > > > -- > > > > - (2^(N-1)) > > -- - (2^(N-1)) pgpwYbPqW1wk8.pgp Description: PGP signature
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On May 21, 2012, at 12:41 PM, Mark Felder wrote: > OK guys I've been talking with another user who can recreate this crash and > the last bit of information we've learned seems to be leaning towards > interrupts/IRQ issues like someone (bz@ perhaps?) suggested. > > I'm still trying to test this myself, but the other user was able to recreate > my crash pretty much on demand. The fix was to not use the first NIC in the > VM because it will always share an IRQ with mpt0. Once mpt0 is on its own the > crash does not seem to be reproducible anymore. > > Before: > > $ vmstat -i > interrupt total rate > irq1: atkbd0 378 0 > irq6: fdc0 9 0 > irq15: ata1 34 0 > irq16: em1687237 1 > irq18: em0 mpt0319094024539 > cpu0: timer236770821400 > Total 556552503940 > > After: > > $ vmstat -i > interrupt total rate > irq1: atkbd0 38 0 > irq6: fdc0 9 0 > irq15: ata1 34 0 > irq16: em1 2811 15 > irq17: em2 5 0 > cpu0: timer71013398 > irq256: mpt0 12163 68 > Total 86073483 > > > Is there any other way we can make mpt0 get its own dedicated IRQ without > having to do this? The problem is that it causes us to have to make rc.conf > changes, pf.conf changes, and who knows what other software could be on these > machines that is trying to bind to a specific NIC... > > > Thanks! > You could try switching mpt to MSI. MSI interrupts are never shared. Add this to /boot/device.hints: > hint.mpt.0.msi_enable="1" -Andrew -- Andrew Boyerabo...@averesystems.com ___ 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"
Something wrong with curs_threads(3X) ?
Hi, In curs_threads(3X), at the beginning of the manual: typedef int (*NCURSES_WINDOW_CB)(WINDOW *, void *); typedef int >(*NCURSES_SCREEN_CB)(SCREEN *, void *); >int set_escdelay(int size); >int set_tabsize(int size); >int use_screen(SCREEN *scr, NCURSES_WINDOW_CB func, void *data); >int use_window(WINDOW *win, NCURSES_SCREEN_CB func, void *data); use_screen => NCURSES_WINDOW_CB use_window = > NCURSES_SCREEN_CB Target is not matched, I'm really confused. So I open /usr/include/curses.h, and find these: extern NCURSES_EXPORT(int) use_screen (SCREEN *, NCURSES_SCREEN_CB, void *); > extern NCURSES_EXPORT(int) use_window (WINDOW *, NCURSES_WINDOW_CB, void > *); Seems much proper. So is this a bug? -- Best regards, Yanhui Shen ___ 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: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
OK guys I've been talking with another user who can recreate this crash and the last bit of information we've learned seems to be leaning towards interrupts/IRQ issues like someone (bz@ perhaps?) suggested. I'm still trying to test this myself, but the other user was able to recreate my crash pretty much on demand. The fix was to not use the first NIC in the VM because it will always share an IRQ with mpt0. Once mpt0 is on its own the crash does not seem to be reproducible anymore. Before: $ vmstat -i interrupt total rate irq1: atkbd0 378 0 irq6: fdc0 9 0 irq15: ata1 34 0 irq16: em1687237 1 irq18: em0 mpt0319094024539 cpu0: timer236770821400 Total 556552503940 After: $ vmstat -i interrupt total rate irq1: atkbd0 38 0 irq6: fdc0 9 0 irq15: ata1 34 0 irq16: em1 2811 15 irq17: em2 5 0 cpu0: timer71013398 irq256: mpt0 12163 68 Total 86073483 Is there any other way we can make mpt0 get its own dedicated IRQ without having to do this? The problem is that it causes us to have to make rc.conf changes, pf.conf changes, and who knows what other software could be on these machines that is trying to bind to a specific NIC... Thanks! ___ 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: Need to revert behavior of OpenSSH to the old key order ...
Folks, Is there a better list for this - perhaps freebsd-security ? I originally posted to -hackers because it *appears* that reverting "rsa, then dsa" to "dsa, then rsa" was a simple change to myproposal.h, but since that doesn't work, and since I haven't gotten any replies here ... Thoughts ? --- On Thu, 5/17/12, Jason Hellenthal wrote: > > > > I have some old 6.x FreeBSD systems that need > their > > > OpenSSH upgraded. > > > > > > > > Everything goes just fine, but when I am > done, existing > > > clients are now presented with this message: > > > > > > > > > > > > WARNING: DSA key found for host hostname > > > > in /root/.ssh/known_hosts:12 > > > > DSA key fingerprint > 4c:29:4b:6e:b8:6b:fa:49... > > > > > > > > The authenticity of host 'hostname > (10.1.2.3)' can't be > > > established > > > > but keys of different type are already known > for this > > > host. > > > > RSA key fingerprint is > a3:22:3d:cf:f2:46:09:f2.. > > > > Are you sure you want to continue connecting > (yes/no) > > > > > > > > > > You must be using different keys for your server > than the > > > one that has > > > been generated before the upgrade. Just copy your > keys over > > > to the new > > > location and restart the server daemon and you > should be > > > fine. > > > > > > copy /etc/ssh/* -> /usr/local/etc/ssh/ > > > > > > You didn't read that error message. > > Sorry I misread that. Decieving message... > > > > > That is not the standard "key mismatch" error that you > assumed it was. Look at it again - it is saying that > we do have a key for this server of type DSA, but the client > is receiving one of type RSA, etc. > > > > The keys are the same - they have not changed at all - > they are just being presented to clients in the reverse > order, which is confusing them and breaking automated, > key-based login. > > > > I need to take current ssh server behavior (rsa, then > dss) and change it back to the old order (dss, then rsa). > > Have you attempted to change that order via sshd_config and > placing the > DSA directive before the RSA one ? > > > -- > > - (2^(N-1)) > ___ 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: ARM + CACHE_LINE_SIZE + DMA
On Fri, 2012-05-18 at 16:13 +0200, Svatopluk Kraus wrote:
> On Thu, May 17, 2012 at 10:07 PM, Ian Lepore
> wrote:
> > On Thu, 2012-05-17 at 15:20 +0200, Svatopluk Kraus wrote:
> >> Hi,
> >>
> >> I'm working on DMA bus implementation for ARM11mpcore platform. I've
> >> looked at implementation in ARM tree, but IMHO it only works with some
> >> assumptions. There is a problem with DMA on memory block which is not
> >> aligned on CACHE_LINE_SIZE (start and end) if memory is not coherent.
> >>
> >> Let's have a buffer for DMA which is no aligned on CACHE_LINE_SIZE.
> >> Then first cache line associated with the buffer can be divided into
> >> two parts, A and B, where A is a memory we know nothing about it and B
> >> is buffer memory. The same stands for last cache line associatted with
> >> the buffer. We have no problem if a memory is coherent. Otherwise it
> >> depends on memory attributes.
> >>
> >> 1. [no cache] attribute
> >> No problem as memory is coherent.
> >>
> >> 2. [write throught] attribute
> >> The part A can be invalidated without loss of any data. It's not problem
> >> too.
> >>
> >> 3. [write back] attribute
> >> In general, there is no way how to keep both parts consistent. At the
> >> start of DMA transaction, the cache line is written back and
> >> invalidated. However, as we know nothing about memory associated with
> >> part A of the cache line, the cache line can be filled again at any
> >> time and messing up DMA transaction if flushed. Even if the cache line
> >> is only filled but not flushed during DMA transaction, we must make it
> >> coherent with memory after that. There is a trick with saving part A
> >> of the line into temporary buffer, invalidating the line, and
> >> restoring part A in current ARM (MIPS) implementation. However, if
> >> somebody is writting to memory associated with part A of the line
> >> during this trick, the part A will be messed up. Moreover, the part A
> >> can be part of another DMA transaction.
> >>
> >> To safely use DMA with no coherent memory, a memory with [no cache] or
> >> [write throught] attributes can be used without problem. A memory with
> >> [write back] attribute must be aligned on CACHE_LINE_SIZE.
> >>
> >> However, for example mbuf, a buffer for DMA can be part of a structure
> >> which can be aligned on CACHE_LINE_SIZE, but not the buffer itself. We
> >> can know that nobody will write to the structure during DMA
> >> transaction, so it's safe to use the buffer event if it's not aligned
> >> on CACHE_LINE_SIZE.
> >>
> >> So, in practice, if DMA buffer is not aligned on CACHE_LINE_SIZE and
> >> we want to avoid bounce pages overhead, we must support additional
> >> information to DMA transaction. It should be easy to support the
> >> information about drivers data buffers. However, what about OS data
> >> buffers like mentioned mbufs?
> >>
> >> The question is following. Is or can be guaranteed for all or at least
> >> well-known OS data buffers which can be part of DMA access that the
> >> not CACHE_LINE_SIZE aligned buffers are surrounded by data which
> >> belongs to the same object as the buffer and the data is not written
> >> by OS when given to a driver?
> >>
> >> Any answer is appreciated. However, 'bounce pages' is not an answer.
> >>
> >> Thanks, Svata
> >
> > I'm adding freebsd-arm@ to the CC list; that's where this has been
> > discussed before.
> >
> > Your analysis is correct... to the degree that it works at all right
> > now, it's working by accident. At work we've been making the good
> > accident a bit more likely by setting the minimum allocation size to
> > arm_dcache_align in kern_malloc.c. This makes it somewhat less likely
> > that unrelated objects in the kernel are sharing a cache line, but it
> > also reduces the effectiveness of the cache somewhat.
> >
> > Another factor, not mentioned in your analysis, is the size of the IO
> > operation. Even if the beginning of the DMA buffer is cache-aligned, if
> > the size isn't exactly a multiple of the cache line size you still have
> > the partial flush situation and all of its problems.
> >
> > It's not guaranteed that data surrounding a DMA buffer will be untouched
> > during the DMA, even when that surrounding data is part of the same
> > conceptual object as the IO buffer. It's most often true, but certainly
> > not guaranteed. In addition, as Mark pointed out in a prior reply,
> > sometimes the DMA buffer is on the stack, and even returning from the
> > function that starts the IO operation affects the cacheline associated
> > with the DMA buffer. Consider something like this:
> >
> >void do_io()
> >{
> >int buffer;
> >start_read(&buffer);
> >// maybe do other stuff here
> >wait_for_read_done();
> >}
> >
> > start_read() gets some IO going, so before it returns a call has been
> > made to bus_dmamap_sync(..., BUS_DMASYNC_PREREAD) and an invalidate gets
> > done on the cacheline containing the variable 'buffer'.
PID/UID namespaces
Hi, While doing some research on FreeBSD jails, I came across an item in the jails' TODO: - be able to have a separate PID space for it - be able to specify a separate UID space for it In other projects, these goals have been accomplished using namespaces. I tried to see if PID/UID namespaces existed in BSD and came across something called Capsicum, a sandboxing project which does not appear to implement outright namespaces for descriptors like PID/UID, but uses something called a "Process Descriptor." Is namespacing of PIDs and UIDs an eventual goal of the jails project of FreeBSD? Thanks, David PS: Excuse my ignorance of anything related to BSD, as I come from a Linux background. -- PGP: 6141 5FFD 11AE 9844 153E F268 7C98 7268 6B19 6CC9 ___ 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: USB over IP
> --047d7b10ce794d5a1004c08b261e > Content-Type: text/plain; charset=ISO-8859-1 > > something similar is being done in the latest versions of qemu. There is a > usb redirection module which is in the form of a client/server architecture > where USB packets are sent over IP. These two modules communicate with > eachother through a protocol developed specifically for the redirection of > USB devices over IP so if I were you I would have a look at the qemu code > for some ideas. do you know if there is a description of the protocol (rfc?) like there is for iscsi, or ata ip? there is alos the usbip project for linux, maybe it can be ported ... cheers, danny ___ 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: USB over IP
something similar is being done in the latest versions of qemu. There is a usb redirection module which is in the form of a client/server architecture where USB packets are sent over IP. These two modules communicate with eachother through a protocol developed specifically for the redirection of USB devices over IP so if I were you I would have a look at the qemu code for some ideas. On Mon, May 21, 2012 at 2:24 PM, Daniel Braniss wrote: > > > > > > Hi, > > > > On 2012-05-21 12:46, Daniel Braniss wrote: > > > I need to control some lab equipment with several usb based controllers > > > (mostly serial) and was wondering if it can be done over IP, there is > such a > > > thing called usbip, but couldn't find what 'server' is needed. > > > all the boxes I found are not cheep, but worse, only provide binaries > > > for windows, or linux. > > > > I'm not entirely sure about your setup - you write usb based controllers > > - and then mostly serial... > > > I know, the word serial is confusing, what I meant is that the USB > connection > (which could be a mass-storage, camera, etc) is in my case serial (ie > rs232) > > > I know it is not strictly speaking usb over ip - but did you look at RFC > > 2217 ? > yes, but it's not relevant to what I'm looking for, I want to send/receive > the USB protocol over IP. I only mentioned the serial (rs232) because I > don't > need speed (as opposed to a camera, audio, etc) > > cheers, >danny > > > ___ > 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: USB over IP
> > > Hi, > > On 2012-05-21 12:46, Daniel Braniss wrote: > > I need to control some lab equipment with several usb based controllers > > (mostly serial) and was wondering if it can be done over IP, there is such a > > thing called usbip, but couldn't find what 'server' is needed. > > all the boxes I found are not cheep, but worse, only provide binaries > > for windows, or linux. > > I'm not entirely sure about your setup - you write usb based controllers > - and then mostly serial... > I know, the word serial is confusing, what I meant is that the USB connection (which could be a mass-storage, camera, etc) is in my case serial (ie rs232) > I know it is not strictly speaking usb over ip - but did you look at RFC > 2217 ? yes, but it's not relevant to what I'm looking for, I want to send/receive the USB protocol over IP. I only mentioned the serial (rs232) because I don't need speed (as opposed to a camera, audio, etc) cheers, danny ___ 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: USB over IP
Hi, On 2012-05-21 12:46, Daniel Braniss wrote: I need to control some lab equipment with several usb based controllers (mostly serial) and was wondering if it can be done over IP, there is such a thing called usbip, but couldn't find what 'server' is needed. all the boxes I found are not cheep, but worse, only provide binaries for windows, or linux. I'm not entirely sure about your setup - you write usb based controllers - and then mostly serial... I know it is not strictly speaking usb over ip - but did you look at RFC 2217 ? https://tools.ietf.org/html/rfc2217 There are several projects supporting RFC 2217: http://ser2net.sourceforge.net/ http://sourceforge.net/projects/sercd/ http://sourceforge.net/projects/cyclades-serial/ "ser2net" and "sredird" are in FreeBSD ports: http://www.freshports.org/comms/ser2net/ http://www.freshports.org/comms/sredird/ /Uffe ___ 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"
USB over IP
I need to control some lab equipment with several usb based controllers (mostly serial) and was wondering if it can be done over IP, there is such a thing called usbip, but couldn't find what 'server' is needed. all the boxes I found are not cheep, but worse, only provide binaries for windows, or linux. cheers, danny ___ 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"
