headers
FreeBSD bugmaster | 1 Mar 2010 12:06
Picon
Favicon

freebsd-embedded@...

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.

S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o misc/136889  embedded   [nanobsd] [path] nanobsd error reporting and other ref
o misc/135588  embedded   [nanobsd] simple patch for adding amd64 support
o misc/52256   embedded   [picobsd] picobsd build script does not read in user/s
o kern/42728   embedded   [picobsd] many problems in src/usr.sbin/ppp/*  after c

4 problems total.
Permalink | Reply | 0 comments |
headers
Joseph Koshy | 1 Mar 2010 18:26
Picon
Favicon

Re: First cut at hwpmc support on MIPS

> FYI, latest patch is here:
> 
> http://people.freebsd.org/~gnn/mipshwpmc_4.diff
> 
> This should address all the issues identified.  I ran a simple test of running ls
> under each event in both system and process modes and that worked like a charm.

These PMCs appear to have the ability to discriminate between 'USER',
'SUPER' and 'KERNEL' CPU modes, but the proposed code in libpmc
does not allow a user to select one or more of these.

[libpmc.c]
+static int
+mips24k_allocate_pmc(enum pmc_event pe, char *ctrspec __unused,
+                 struct pmc_op_pmcallocate *pmc_config __unused)
+{
+       switch (pe) {
+       default:
+               break;
+       }
+       
+       return (0);
+}

If you wish to implement these qualifiers, function iaf_allocate_pmc()
in libpmc.c would be useful as a template.  If not, it would be prudent
to add a sentence in the manual page so that users know exactly what is
being measured.

The patch looks fine otherwise.  Nice work!
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pawel Jakub Dawidek | 2 Mar 2010 08:17
Picon
Favicon

Re: GEOM_ULZMA

On Fri, Feb 19, 2010 at 04:36:44PM +0200, Alexandr Rybalko wrote:
> Hi,
> I wrote a module GEOM_ULZMA (such as GEOM_UZIP, but compression with lzma), [...]

Wouldn't it be better to modify geom_uzip to be universal decompression
class with various algorithms implemented as plugins?
This is bascially what I did for the LABEL class - before we had VOL_FFS
class only for UFS labels.

> [...] in connection with this is an issue best left lzma
> code in the file "geom_ulzma.c" or store lzma library separately. If separately, then where better?

Definiatelly separately, not sure where. There is ongoing discussion
somwhere on importing this algorithm to the base for tar(1) to use, it
would be best to have only one copy of code in the tree.

--

-- 
Pawel Jakub Dawidek                       http://www.wheelsystems.com
pjd@...                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
Permalink | Reply | 15 comments |
headers
Alexandr Rybalko | 2 Mar 2010 09:47
Picon
Favicon

Re: GEOM_ULZMA

Hi,

On Tue, 2 Mar 2010 08:17:36 +0100
Pawel Jakub Dawidek <pjd@...> wrote:

>> On Fri, Feb 19, 2010 at 04:36:44PM +0200, Alexandr Rybalko wrote:
>> > Hi,
>> > I wrote a module GEOM_ULZMA (such as GEOM_UZIP, but compression with lzma), [...]
>> 
>> Wouldn't it be better to modify geom_uzip to be universal decompression
>> class with various algorithms implemented as plugins?
>> This is bascially what I did for the LABEL class - before we had VOL_FFS
>> class only for UFS labels.

Yes, you are right, but problem where in kernel code store LZMA code, and what to do with different versions
of it?

>> 
>> > [...] in connection with this is an issue best left lzma
>> > code in the file "geom_ulzma.c" or store lzma library separately. If separately, then where better?
>> 
>> Definiatelly separately, not sure where. There is ongoing discussion
>> somwhere on importing this algorithm to the base for tar(1) to use, it
>> would be best to have only one copy of code in the tree.

I have already said, that it would be good for embedded platforms have only one copy of the code for the kernel
and userland.
It is not thought of how done it.

>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dimitry Andric | 2 Mar 2010 20:32
Favicon

Re: GEOM_ULZMA

On 2010-03-02 09:47, Alexandr Rybalko wrote:
>>> Definiatelly separately, not sure where. There is ongoing discussion
>>> somwhere on importing this algorithm to the base for tar(1) to use, it
>>> would be best to have only one copy of code in the tree.
> I have already said, that it would be good for embedded platforms have only one copy of the code for the
kernel and userland.
> It is not thought of how done it.

I think Pawel means the *source* code in this case, not the executable
code.  E.g. lzma source should most likely go under /usr/src/contrib,
and be built separately for kernel and userland.
Permalink | Reply | 0 comments |
headers
Alex RAY | 2 Mar 2010 22:35
Gravatar

Re: GEOM_ULZMA

On Tue, 02 Mar 2010 20:32:20 +0100
Dimitry Andric <dimitry@...> wrote:

> On 2010-03-02 09:47, Alexandr Rybalko wrote:
> >>> Definiatelly separately, not sure where. There is ongoing discussion
> >>> somwhere on importing this algorithm to the base for tar(1) to use, it
> >>> would be best to have only one copy of code in the tree.
> > I have already said, that it would be good for embedded platforms have only one copy of the code for the
kernel and userland.
> > It is not thought of how done it.
> 
> I think Pawel means the *source* code in this case, not the executable
> code.  E.g. lzma source should most likely go under /usr/src/contrib,
> and be built separately for kernel and userland.

I understand. 
I'm trying to think about the future of FreeBSD in embedded. :)

--

-- 
Alexandr Rybalko <ray@...>
aka Alex RAY <ray@...>
Permalink | Reply | 0 comments |
headers
Pawel Jakub Dawidek | 3 Mar 2010 07:35
Picon
Favicon

Re: GEOM_ULZMA

On Tue, Mar 02, 2010 at 08:32:20PM +0100, Dimitry Andric wrote:
> On 2010-03-02 09:47, Alexandr Rybalko wrote:
> >>>Definiatelly separately, not sure where. There is ongoing discussion
> >>>somwhere on importing this algorithm to the base for tar(1) to use, it
> >>>would be best to have only one copy of code in the tree.
> >I have already said, that it would be good for embedded platforms have 
> >only one copy of the code for the kernel and userland.
> >It is not thought of how done it.
> 
> I think Pawel means the *source* code in this case, not the executable
> code.  E.g. lzma source should most likely go under /usr/src/contrib,
> and be built separately for kernel and userland.

If it is going to be used be the kernel it has to be under sys/.

And yes, I was talking about one copy of the source, not executable.
I think it would be bad idea to do compression in the kernel for
userland applications for many reasons - the most important one is
security. Look at projects like Capsicum where Robert closed for example
gzip in a tight sandbox and gzip is not even set-uid and giving it
chance to gain kernel access when bug is found is very, very bad.
Another reason is performance. You can see how much faster, eg. openssl
crypto is when doing it in userland and when forcing it to use software
crypto from the opencrypto kernel framework.

--

-- 
Pawel Jakub Dawidek                       http://www.wheelsystems.com
pjd@...                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexandr Rybalko | 4 Mar 2010 10:08
Picon
Favicon

Re: GEOM_ULZMA

On Wed, 3 Mar 2010 07:35:55 +0100
Pawel Jakub Dawidek <pjd@...> wrote:

>> On Tue, Mar 02, 2010 at 08:32:20PM +0100, Dimitry Andric wrote:
>> > On 2010-03-02 09:47, Alexandr Rybalko wrote:
>> > >>>Definiatelly separately, not sure where. There is ongoing discussion
>> > >>>somwhere on importing this algorithm to the base for tar(1) to use, it
>> > >>>would be best to have only one copy of code in the tree.
>> > >I have already said, that it would be good for embedded platforms have 
>> > >only one copy of the code for the kernel and userland.
>> > >It is not thought of how done it.
>> > 
>> > I think Pawel means the *source* code in this case, not the executable
>> > code.  E.g. lzma source should most likely go under /usr/src/contrib,
>> > and be built separately for kernel and userland.
>> 
>> If it is going to be used be the kernel it has to be under sys/.
>> 
>> And yes, I was talking about one copy of the source, not executable.
>> I think it would be bad idea to do compression in the kernel for
>> userland applications for many reasons - the most important one is
>> security. Look at projects like Capsicum where Robert closed for example
>> gzip in a tight sandbox and gzip is not even set-uid and giving it
>> chance to gain kernel access when bug is found is very, very bad.
>> Another reason is performance. You can see how much faster, eg. openssl
>> crypto is when doing it in userland and when forcing it to use software
>> crypto from the opencrypto kernel framework.

Ok, already forgotten. 
Well, LZMA code is not so big, so will use two copies for kernel and for userland.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ulf Lilleengen | 4 Mar 2010 11:21
Picon
Picon
Favicon

Re: GEOM_ULZMA

On Fri, Feb 19, 2010 at 04:36:44PM +0200, Alexandr Rybalko wrote:
> Hi,
> I wrote a module GEOM_ULZMA (such as GEOM_UZIP, but compression with lzma), in connection with this is an
issue best left lzma
> code in the file "geom_ulzma.c" or store lzma library separately. If separately, then where better?
> 
> Maybe in future make lzma and gzip library kernel interface for embedded?
> Then in one instance of code, userland can use compression via kernel.
> 

What are the cons against combining uzip/ulzma into a geom_z/geom_compress
module that can support different compression schemes? I think this makes
more sense than having different geom modules for each compression scheme.

--

-- 
Ulf Lilleengen
Permalink | Reply | 6 comments |
headers
Alexandr Rybalko | 4 Mar 2010 12:39
Picon
Favicon

Re: GEOM_ULZMA

On Thu, 4 Mar 2010 11:21:59 +0100
Ulf Lilleengen <lulf@...> wrote:

>> On Fri, Feb 19, 2010 at 04:36:44PM +0200, Alexandr Rybalko wrote:
>> > Hi,
>> > I wrote a module GEOM_ULZMA (such as GEOM_UZIP, but compression with lzma), in connection with this is
an issue best left
>> > lzma code in the file "geom_ulzma.c" or store lzma library separately. If separately, then where better?
>> > 
>> > Maybe in future make lzma and gzip library kernel interface for embedded?
>> > Then in one instance of code, userland can use compression via kernel.
>> > 
>> 
>> What are the cons against combining uzip/ulzma into a geom_z/geom_compress
>> module that can support different compression schemes? I think this makes
>> more sense than having different geom modules for each compression scheme.

I agree with you, since this modules need for reducing sizes, so user need configure what type they need.

>> 
>> -- 
>> Ulf Lilleengen

--

-- 
Рыбалко Александр
Консультант D-Link Украина
Permalink | Reply | 0 comments |

Gmane