Re: Source File Permissions

2018-05-01 Thread Christian Mauderer 
Am 01.05.2018 um 00:23 schrieb Joel Sherrill:
> 
> 
> On Mon, Apr 30, 2018 at 3:18 AM, Christian Mauderer  > wrote:
> 
> Am 29.04.2018 um 23:08 schrieb Joel Sherrill:
> > 
> > 
> > On Sun, Apr 29, 2018, 3:32 PM Christian Mauderer  
> > >> wrote:
> > 
> >     Am 28.04.2018 um 21:45 schrieb Gedare Bloom:
> >     > On Thu, Apr 26, 2018 at 7:52 PM, Joel Sherrill  
> >     >> wrote:
> >     >> Hi
> >     >>
> >     >> Teaching the class this week, i have noticed that randomly some
> >     >> files are executable. I was going to change this but then 
> realized
> >     >> that we should all agree on what the permissions on the files and
> >     >> directories in the tree(s) should be.
> >     >>
> >     >> I lean to either:
> >     >>
> >     >> + 664 for files and 775 for directories
> >     >>
> >     >> But could be talked into tighter permissions for group and world.
> >     >> Whatever we do, it should be consistent and added to the Coding
> >     >> Conventions.
> >     >>
> >     >
> >     > Your proposal is sensible to me.
> > 
> >     Hello Joel,
> > 
> >     I wouldn't really have a problem with these. But I think the more 
> usual
> >     ones would be 644 and 755.
> > 
> >     If I create a new file using `touch somefile` in a directory with 
> 775, I
> >     still get a 644 file (at least on my Linux machine - I'm not sure
> >     whether it is configuration dependant). I think that we will get a 
> lot
> >     of patches with "wrong" permissions if we use 664 and 775. So maybe 
> it
> >     would be good to have some reasons for using these wider group
> >     permissions.
> > 
> > 
> > The command you are thinking of is umask to set your default file
> > permissions. 
> > 
> 
> I knew I have seen a setting sometimes. You are right: I have though of
> umask. I only don't need it often enough to remember ;-)
> 
> > 
> >     The only setup that I could think of where such rights might could 
> be
> >     useful is one where one user updates the code while some other user 
> (for
> >     example a build bot) has to run a bootstrap to build the tree. But 
> I'm
> >     quite sure that even for that case, there are some better solutions
> >     (e.g. one working tree that only pushes to a build bot tree).
> > 
> > 
> > If all commits go through a git or patch tester server, i would assume
> > that we are getting the permissions set by the patch submitter.
> > 
> > I suspect (no investigation) that we could have a git check that ensures
> > specific permissions based on the file extension.
> > 
> 
> That would be great.
> 
> 
> Should we file that as an admin "wish list" item? 
> 

I think in the long run, that would be something like the linux
checkpatch.pl script that checks whether the coding style matches the
ones that we accept:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/checkpatch.pl?h=v4.17-rc3

But I don't think that anyone has the time to do it. So really a long
term project. Beneath that even if we already have a coding style
recommendation such a script would for sure start the discussion about
THE RIGHT CODING STYLE which is quite a matter of faith and therefore a
really annoying discussion (and please let's not start it here and now).

> 
> > 
> >     Any special reasons, use cases or experiences where the 664 and 775
> >     would be superior to 644 and 755?
> > 
> > 
> > No. I just remember historically using those on real multi-user devel
> > machines so everyone on a team could share source.
> > 
> > I think we all agree it should be standardized. That's a good step.
> > 
> > I will look at git, GNU recommendations and a few packages to see what
> > they do. Then make a proposal which might include ways to try to keep
> > this standardized.
> > 
> 
> Maybe it's already decided by git:
> 
> I did a quick test: I initialized an empty repository (called test) and
> created the following files there:
> 
> -rw-r--r-- 1 christian users 0 30. Apr 10:05 644
> -rw-rw-r-- 1 christian users 0 30. Apr 10:05 664
> -rw-rw-rw- 1 christian users 0 30. Apr 10:05 666
> -rwxr-xr-x 1 christian users 0 30. Apr 10:04 755
> -rwxrwxr-x 1 christian users 0 30. Apr 10:05 775
> -rwxrwxrwx 1 christian users 0 30. Apr 10:05 777
> 
> Then I did a `git add .` and commited it. If I clone that repository
> with `git clone test test2` my test2 folder contains the following
> files:
> 
> -rw-r--r-- 1 christian users 0 30. Apr 10:07 644
> -rw-r--r-- 1 christian users

Re: [PATCH 9/9] telnetd: Use syslog() instead of printk()

2018-05-01 Thread Sebastian Huber 
- Am 1. Mai 2018 um 0:12 schrieb joel j...@rtems.org:

> Sorry to ask this but is there a syslog service that needs to be started
> before
> telnetd? Is there some dependency?

The syslog() function uses printf() for output without extra initialization.

> 
> What's the rationale for this change?

printk() should not be used for normal output. The syslog9) is already used in 
other places of the telnetd and ftpd.

> 
> On Mon, Apr 30, 2018 at 4:48 AM, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
> 
>> Update #3419.
>> ---
>>  cpukit/telnetd/pty.c  | 10 --
>>  cpukit/telnetd/telnetd-init.c |  2 +-
>>  2 files changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/cpukit/telnetd/pty.c b/cpukit/telnetd/pty.c
>> index d41de97d85..14d688018f 100644
>> --- a/cpukit/telnetd/pty.c
>> +++ b/cpukit/telnetd/pty.c
>> @@ -42,6 +42,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  /*-*/
>>  #define IAC_ESC255
>> @@ -453,8 +454,13 @@ rtems_device_driver my_pty_initialize(
>>  chmod(telnet_ptys[ndx].devname,0660);
>>  chown(telnet_ptys[ndx].devname,2,0); /* tty,root*/
>>};
>> -  printk("Device: /dev/pty%X../dev/pty%X (%d)pseudo-terminals
>> registered.\n",
>> -  0,rtems_telnetd_maximum_ptys-1,rtems_telnetd_maximum_ptys);
>> +  syslog(
>> +LOG_KERN | LOG_INFO,
>> +"/dev/pty%X../dev/pty%X (%d) pseudo-terminals registered.\n",
>> +0,
>> +rtems_telnetd_maximum_ptys - 1,
>> +rtems_telnetd_maximum_ptys
>> +  );
>>
>>return RTEMS_SUCCESSFUL;
>>  }
>> diff --git a/cpukit/telnetd/telnetd-init.c b/cpukit/telnetd/telnetd-init.c
>> index 760db41fcc..7762ad70ba 100644
>> --- a/cpukit/telnetd/telnetd-init.c
>> +++ b/cpukit/telnetd/telnetd-init.c
>> @@ -12,7 +12,7 @@
>>
>>  #include 
>>
>> -int rtems_initialize_telnetd( void )
>> +rtems_status_code rtems_telnetd_initialize( void )
>>  {
>>return rtems_telnetd_start( &rtems_telnetd_config );
>>  }
>> --
>> 2.12.3
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: x86_64 port and BSP (GSoC 2018)

2018-05-01 Thread Amaan Cheval 
Quick update: My x86_64 stub port compiles and can be linked to all default
tests now! _dance_

I've pushed the stub port for the x86_64 to my fork on Github; the commits
are horribly messy (I did most of the work aiming for the stub to be one
commit, then later I realized several commits would make more sense for
when I'll have to rebase and catch up with master - TL;DR: ignore the
commits, I'll squash and make them make more sense later).

https://github.com/AmaanC/rtems/tree/ac/stub-x86-link-tests-pre-bspreorg-bak

It depends on the x86_64 tools being updated, so we need the patch I've
already made[1] to rtems-source-builder, along with one I'll make after my
patch to gcc[2] adding crti.o and crtn.o is accepted.

Using this configure command:

../kernel/configure --prefix=$HOME/bin/rtems/5-x86_64
--target=x86_64-rtems5 --enable-rtemsbsp=no_bsp --enable-posix
--enable-tests --enable-maintainer-mode

No errors were logged while running "make", and there are now 568 "*.exe"s
in the ./x86_64-rtems5/c/no_bsp/testsuites folders (using "find").

Next up:

- Restructure to use bsps dir
- Figure out specifics of linkcmds and bsp_specs (currently it's just a
hacky mashup of the one in no_bsp and pc386)
- Work out how

[1] https://lists.rtems.org/pipermail/devel/2018-April/020883.html
[2] https://gcc.gnu.org/ml/gcc-patches/2018-05/msg7.html
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Misplaced Directories?

2018-05-01 Thread Sebastian Huber 

On 30/04/18 23:36, Joel Sherrill wrote:

While teaching the class last week, I got the privilege of adapting on
the fly to the new layout. Mostly went well but I made some notes on
some directories in cpukit whose placement seems inconsistent with
other similar directories. I thought I would toss out my list and see
what others thought.

+ rhealstone not under benchmarks

+ libz is a top level directory but xz is under libmisc

+ libpci is not under dev

+ drvmgr is not under dev

+ libi2c (yes legacy) is not under dev

+ devnull is not under dev

+ fb is not under dev

+ mouse is not under dev

+ fsmount under libfs?

I think that's it from my notes. Any comments or thoughts?


I would leave the source files in cpukit where they are. A proper file 
history is more important than a fancy directory layout from my point of 
view.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel