Re: IoT OS

2016-01-22 Thread Julian Elischer 

On 22/01/2016 2:08 AM, Mathieu Prevot wrote:

2016-01-21 17:38 GMT+01:00 NGie Cooper :


On Jan 21, 2016, at 08:34, Jan Bramkamp  wrote:


On 21/01/16 17:19, Mathieu Prevot wrote:
Dear all,

I would like to connect several connected object (with homogeneous or
heterogenous hardare: intel edison,  samsung artik, apple AX, intel

core,

etc) so the calculation needs, the storage/memory, the connection, etc

are

decoupled; hence we can reach an ecosystem with several clouds.

How do you recommend to reach that ? from the kernel, a module, or
eventually a software ?

Your message contains neither enough information nor a precise enough

question for anyone to provide you a helpful answer.

Please describe your problem in sufficient detail and reformulate your

question. If you still think these mailing lists (current@ and hackers@)
are a good audience for your question afterward ask them again.

It depends on your workload and hardware requirements (there isn't a
simple answer to your question because you didn't describe what you needed
with concrete requirements).

I would talk to cem@. He's working on ioat(4) on head for us ($work).
Thanks,
-NGie


Say all objects are connected peer to peer with wifi, some of them are
connected to internet through gsm network or wifi to a box. These object
are moving in space, and for some reasons, connections are dynamical and
can be severely impaired or lost.

They have incoming local streams of data (eg HD videos, accelerometer, GPS,
other wifi and gsm signals, etc).

I would like to abstract the CPU layer, storage layer, and internet
connection so that in realtime results of one of my objects are saved if
this object dies, so that if one of the object giving internet access to
the group loose its connection, the redundancy allows the group of object
not to lose internet connection.

Can I consider these as different load balancing layers ? Do you recommend
to implement this at the kernel layer or at an API layer ? Can I see that
as a lightweight cluster ?

I think the API is more flexible, especially if I have an heterogeneous (by
CPU, OS) set of connected object. However, working at the kernel level
allows existing programs not to be rewritten. What are your thoughts ?

Do you recommend another list ?


This is still very hard to understand.
Are you planning to work with some API that is described in a document 
somewhere?

if so please give links.



Thanks
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"



___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: LibreOffice doesn't work anymore

2016-01-22 Thread Vladimir Zakharov 
On Fri, Jan 22, 2016, Konstantin Belousov wrote:
> On Fri, Jan 22, 2016 at 11:17:08AM +0300, Vladimir Zakharov wrote:
> > Hello!
> > 
> > Updating from r294203 to r294460 has broken LibreOffice. Now LO core
> > dumps with the following message:
> > 
> > GLib (gthread-posix.c): Unexpected error from C library during 
> > 'pthread_key_create': Function not implemented.  Aborting.
> > 
> > Here is the backtrace:
> > 
> > GNU gdb 6.1.1 [FreeBSD]
> > ...
> > This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols 
> > found)...
> > Core was generated by `soffice.bin'.
> > Program terminated with signal 6, Aborted.
> > Reading symbols from 
> > /usr/local/lib/libreoffice/program/libuno_sal.so.3...(no debugging symbols 
> > found)...done.
> > Loaded symbols for /usr/local/lib/libreoffice/program/libuno_sal.so.3
> > ...
> > (skipped lots of "Reading symbols ... (no debugging symbols found)" and 
> > "Loaded symbols ..." strings)
> > ...
> Did you skipped the message about libthr.so.3 ?
> 
> If yes, update to at least r294470.

Works for me again on r294556. Thanks.

-- 
Regards, | "In theory there is no difference between theory
  Vladimir Zakharov  | and practice. In practice there is."- Yogi Berra
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: LibreOffice doesn't work anymore

2016-01-22 Thread Vladimir Zakharov 
On Fri, Jan 22, 2016, Konstantin Belousov wrote:
> On Fri, Jan 22, 2016 at 11:17:08AM +0300, Vladimir Zakharov wrote:
> > Hello!
> > 
> > Updating from r294203 to r294460 has broken LibreOffice. Now LO core
> > dumps with the following message:
> > 
> > GLib (gthread-posix.c): Unexpected error from C library during 
> > 'pthread_key_create': Function not implemented.  Aborting.
> > 
> > Here is the backtrace:
> > 
> > GNU gdb 6.1.1 [FreeBSD]
> > ...
> > This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols 
> > found)...
> > Core was generated by `soffice.bin'.
> > Program terminated with signal 6, Aborted.
> > Reading symbols from 
> > /usr/local/lib/libreoffice/program/libuno_sal.so.3...(no debugging symbols 
> > found)...done.
> > Loaded symbols for /usr/local/lib/libreoffice/program/libuno_sal.so.3
> > ...
> > (skipped lots of "Reading symbols ... (no debugging symbols found)" and 
> > "Loaded symbols ..." strings)
> > ...
> Did you skipped the message about libthr.so.3 ?
Yes, there was message about libthr.so.3 in omitted part.

> 
> If yes, update to at least r294470.
> 
Ok. Started updating to r294556.

-- 
Regards, | "In theory there is no difference between theory
  Vladimir Zakharov  | and practice. In practice there is."- Yogi Berra
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

LibreOffice doesn't work anymore

2016-01-22 Thread Vladimir Zakharov 
Hello!

Updating from r294203 to r294460 has broken LibreOffice. Now LO core
dumps with the following message:

GLib (gthread-posix.c): Unexpected error from C library during 
'pthread_key_create': Function not implemented.  Aborting.

Here is the backtrace:

GNU gdb 6.1.1 [FreeBSD]
...
This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols 
found)...
Core was generated by `soffice.bin'.
Program terminated with signal 6, Aborted.
Reading symbols from /usr/local/lib/libreoffice/program/libuno_sal.so.3...(no 
debugging symbols found)...done.
Loaded symbols for /usr/local/lib/libreoffice/program/libuno_sal.so.3
...
(skipped lots of "Reading symbols ... (no debugging symbols found)" and "Loaded 
symbols ..." strings)
...
Reading symbols from /usr/local/lib/libtasn1.so.6...(no debugging symbols 
found)...done.
Loaded symbols for /usr/local/lib/libtasn1.so.6
Reading symbols from /usr/local/lib/libnettle.so.4...Error while reading shared 
library symbols:
Dwarf Error: wrong version in compilation unit header (is 3, should be 2) [in 
module /usr/local/lib/libnettle.so.4]
Reading symbols from /usr/local/lib/libhogweed.so.2...Error while reading 
shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 3, should be 2) [in 
module /usr/local/lib/libhogweed.so.2]
Reading symbols from /usr/local/lib/libgmp.so.10...(no debugging symbols 
found)...done.
Loaded symbols for /usr/local/lib/libgmp.so.10
Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x000800dc9b0a in thr_kill () from /lib/libc.so.7
[New LWP 100189]
(gdb)


-- 
Regards, | "In theory there is no difference between theory
  Vladimir Zakharov  | and practice. In practice there is."- Yogi Berra
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: LibreOffice doesn't work anymore

2016-01-22 Thread Konstantin Belousov 
On Fri, Jan 22, 2016 at 11:17:08AM +0300, Vladimir Zakharov wrote:
> Hello!
> 
> Updating from r294203 to r294460 has broken LibreOffice. Now LO core
> dumps with the following message:
> 
> GLib (gthread-posix.c): Unexpected error from C library during 
> 'pthread_key_create': Function not implemented.  Aborting.
> 
> Here is the backtrace:
> 
> GNU gdb 6.1.1 [FreeBSD]
> ...
> This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols 
> found)...
> Core was generated by `soffice.bin'.
> Program terminated with signal 6, Aborted.
> Reading symbols from /usr/local/lib/libreoffice/program/libuno_sal.so.3...(no 
> debugging symbols found)...done.
> Loaded symbols for /usr/local/lib/libreoffice/program/libuno_sal.so.3
> ...
> (skipped lots of "Reading symbols ... (no debugging symbols found)" and 
> "Loaded symbols ..." strings)
> ...
Did you skipped the message about libthr.so.3 ?

If yes, update to at least r294470.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Too low PTHREAD_STACK_MIN value?

2016-01-22 Thread David Chisnall 
On 21 Jan 2016, at 16:02, Ed Maste  wrote:
> 
> I found that lang/polyml uses PTHREAD_STACK_MIN for a trivial signal
> handler thread it creates[1]. They found it was too small and
> implemented a 4K minimum bound to fix polyml on FreeBSD[2]. Even if
> this isn't really the intended use of PTHREAD_STACK_MIN it suggests
> the 2K x86 minimum may indeed be too low.
> 
> I ran into this while trying LLVM's libunwind, which requires more
> stack space. 2K is certainly too low with LLVM libunwind. Is it
> reasonable to just increase it to say 8K?

I don’t really like this solution.  PTHREAD_STACK_MIN is the size for a stack 
that does not do anything.  You should never use it without adding the amount 
that you are going to need (which might be nothing if you are running code from 
a language that does not use a conventional C-style stack, but still wants to 
use OS threads).  Making it larger because a specific kind of thing that some 
consumers want to do with it needs more space is definitely against the spirit 
of the value and potentially harmful as it means that people using it correctly 
will be using a lot more memory per thread.

David

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: RCTL and VIMAGE for 11.0-RELEASE

2016-01-22 Thread Ernie Luzar 

Bjoern A. Zeeb wrote:

On 24 Aug 2015, at 19:08 , Mark Felder  wrote:

What is preventing RCTL from being enabled right now? Any known/serious
blockers?


It’s enabled in GENERIC.



And the same for VIMAGE? I know there were issues with some firewalls,
but I'm not sure where that stands today. Does it degrade network
performance in a measurable way?


Ignoring performance for a second, there is more than just firewalls that needs to be done.  I started writing a plan for the next 4 months 
yesterday.  Most of this was done a few years ago and never made it to 
HEAD.  It needs to be re-validated.  If my plan comes together we’ll 
have another 4 month window before the 11 release cycle will start.


/bz



It's been 5 months since the above was posted. What is the status of 
VIMAGE as part of base in 11.0-RELEASE?


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: IoT OS

2016-01-22 Thread Rang, Anton 
>Say all objects are connected peer to peer with wifi, some of them are 
>connected to internet through gsm network or wifi to a box.
>These object are moving in space, and for some reasons, connections are 
>dynamical and can be severely impaired or lost.
>
>They have incoming local streams of data (eg HD videos, accelerometer, GPS, 
>other wifi and gsm signals, etc).
>
>I would like to abstract the CPU layer, storage layer, and internet connection 
>so that in realtime results of one of my objects are saved
>if this object dies, so that if one of the object giving internet access to 
>the group loose its connection, the redundancy allows the group of object not 
>to lose internet connection.
>
>Can I consider these as different load balancing layers ? Do you recommend to 
>implement this at the kernel layer or at an API layer ?
>Can I see that as a lightweight cluster ?
>
>I think the API is more flexible, especially if I have an heterogeneous (by 
>CPU, OS) set of connected object. However, working at the kernel level allows 
>existing programs not to be rewritten.
>What are your thoughts ?

===

OK, I think I understand your question now.

This isn't the right list for it, though I'm not sure where the right place to 
go would be -- it's not FreeBSD-specific, in any case. There are academic 
research groups looking into this type of problem; for instance, in the area of 
sensor networks (ACM Transactions on Sensor Networks covers some of these 
areas). There may be USENET groups which cover this area.

To cover your three areas, which I think require somewhat different solutions --

(a) CPU layer.  I don't really recommend trying to abstract this.  You could 
use a virtual machine to hide the underlying architecture, and checkpoint state 
periodically, but this is likely to slow down execution too much to be useful.  
If the issue that a service may become unavailable, I'd recommend a middleware 
layer which can detect this and recover by starting a new instance of the 
service. Middleware layers like ZeroMQ, and clustering software, may be a 
useful starting point.  This does mean that stateful connections (like reading 
a video stream) won't recover cleanly, though; the client would need to 
reconnect to attach to the new instance of the service.  If you really need 
that, it's going to be hard.

(b) Storage layer.  Look into highly-available clustered storage solutions.  If 
you can use key-value or some other simplified storage model, do it.  There are 
clustered file systems but probably none freely available that would work on 
the scale you envision and give decent performance.  There are more 
alternatives if you're flexible about the format in which you're storing data 
(e.g. replicated object stores).

(c) Networking layer; or internet. If you can drop & re-establish a connection, 
or if every node has its own IP address (IPv6), this should be pretty 
straightforward; software could detect loss of connection and change the 
routing used to go through a different system. If not, you'll be a bit limited 
since mirroring TCP state between nodes would be too slow. This is a case where 
the existing operating system kernels are likely to do most of what you need; 
you simply need to add a layer to detect routing problems and select a new 
internet gateway appropriately.

I'd avoid implementing any clustering within the kernel, in part because if you 
have a wide variety of objects you may not want the same kernel on all of them, 
and in part because debugging & recovery is much harder. You're unlikely to 
want to run most existing software on such a system anyway (especially if they 
have relatively weak processors); you're better off writing to a set of 
clustering APIs for storage and state, at least. For networking, as mentioned, 
you can likely use the existing TCP stack & just add controls to redirect 
traffic as needed.

-- Anton

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

HPN and None options in OpenSSH

2016-01-22 Thread Dag-Erling Smørgrav 
The HPN and None cipher patches have been removed from FreeBSD-CURRENT.
I intend to remove them from FreeBSD-STABLE this weekend.

The HPN patches were of limited usefulness and required a great deal of
effort to maintain in our tree.  The None cipher patch was less onerous,
but it was a terrible idea with a very small user base since it was a
compile-time option and off by default.

The HPN-related configuration variables have been marked deprecated,
while those related to the None cipher have been marked unsupported.
This means that the former will be accepted with a warning, whereas the
latter will result in an error.

Most users will not be affected by this change.  Those who are should
switch to the openssh-portable port, which still offers both patches,
with HPN enabled by default.

It is expected that FreeBSD 10.3 will ship with OpenSSH 7.1p2, with a
number of modifications intended to reduce the impact of upstream
changes on existing systems.

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: HPN and None options in OpenSSH

2016-01-22 Thread Julian Elischer 

On 22/01/2016 10:31 PM, Dag-Erling Smørgrav wrote:

The HPN and None cipher patches have been removed from FreeBSD-CURRENT.
I intend to remove them from FreeBSD-STABLE this weekend.

The HPN patches were of limited usefulness and required a great deal of
effort to maintain in our tree.  The None cipher patch was less onerous,
but it was a terrible idea with a very small user base since it was a
compile-time option and off by default.

The HPN-related configuration variables have been marked deprecated,
while those related to the None cipher have been marked unsupported.
This means that the former will be accepted with a warning, whereas the
latter will result in an error.

Most users will not be affected by this change.  Those who are should
switch to the openssh-portable port, which still offers both patches,
with HPN enabled by default.

It is expected that FreeBSD 10.3 will ship with OpenSSH 7.1p2, with a
number of modifications intended to reduce the impact of upstream
changes on existing systems.

what is the internal window size in the new ssh?


DES


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"