Re: ELFOSABI_NETBSD

On 07.04.2017 23:10, Christos Zoulas wrote: > On Apr 7, 7:17pm, n...@gmx.com (Kamil Rytarowski) wrote: > -- Subject: ELFOSABI_NETBSD > > | Currently we set e_ident[EI_OSABI] to ELFOSABI_SYSV. This makes parsing > | NetBSD core(5) core files cross-system little bit less obvious.

ELFOSABI_NETBSD

What's the purpose of ELFOSABI_NETBSD on NetBSD? Currently we set e_ident[EI_OSABI] to ELFOSABI_SYSV. This makes parsing NetBSD core(5) core files cross-system little bit less obvious. In LLDB we are recognized as generic or unknown unix. Function ELFNAMEEND(coredump): 161 /* XXX

Re: Interested in ext3fs for GSoC

> Sent: Wednesday, March 29, 2017 at 9:51 PM > From: "Christos Zoulas" > To: tech-kern@netbsd.org > Subject: Re: Interested in ext3fs for GSoC > > In article > , > Miles Fertel

Re: Prospective project for Summer of Code.

On 21.03.2017 13:43, Joerg Sonnenberger wrote: > On Tue, Mar 21, 2017 at 01:38:09PM +0100, Kamil Rytarowski wrote: >> I planned to spend my time on kqueue(2)/kevent(2) and aio(3) after May >> (full-time effort, but not GSoC). There is a list of bug reports around >> these

Re: Prospective project for Summer of Code.

On 20.03.2017 23:43, Raunaq Kochar wrote: > Hi, > I am a Masters in Computer Science student at Stony Brook University > looking to work as part of the Google Summer of Code on the Real > Asynchronous I/O or Parallelize Page Queues projects. Welcome! I planned to spend my time on

Re: PCU vs. ptrace

On 04.03.2017 18:25, Chuck Silvers wrote: > in the case of PT_GETFPREGS or PT_SETFPREGS, the target thread will be > stopped, but for PT_DUMPCORE the target thread supposedly may be running. > it appears to me that the PCU save/discard code does the right thing even for > a running thread, though

Porting ptrace(2) software to NetBSD

I've prepared slides to illustrate the concepts of porting ptrace(2) software from Linux and other BSDs to NetBSD. http://netbsd.org/~kamil/ptrace-netbsd/presentation.html I used www/py-landslide to generate the HTML presentation, my input was typed in markdown:

Re: PAX mprotect and JIT

On 26.02.2017 16:03, Joerg Sonnenberger wrote: > On Sun, Feb 26, 2017 at 02:52:39PM +0100, Kamil Rytarowski wrote: >> It looks difficult to understand on the first sight, the need to >> "reinvent" malloc(3) with this approach. > > The point here is to have strict

Re: PAX mprotect and JIT

On 26.02.2017 15:05, co...@sdf.org wrote: > On Sun, Feb 26, 2017 at 02:52:39PM +0100, Kamil Rytarowski wrote: >> Can we have something like MAP_NOMPROTECT? Something like it would be >> used to mmap(2) RWX region: >> >> void *mapping = mmap(NULL, rounded_s

Re: PAX mprotect and JIT

On 25.02.2017 22:35, Joerg Sonnenberger wrote: > Hi all, > at the moment, PAX mprotect makes it very expensive to implement any > form of JIT. It is not possible to switch a page from writeable to > executable. It is not possible to use anonymous memory for JIT in > multi-threaded applications as

Re: CVS commit: src/sys/sys

On 23.02.2017 09:48, Robert Elz wrote: > Date:Thu, 23 Feb 2017 15:32:16 +0800 (PHT) > From:Paul Goyette <p...@whooppee.com> > Message-ID: <pine.neb.4.64.1702231527400.4...@speedy.whooppee.com> > > | On Thu, 23 Feb 2017, Kamil Rytarowsk

Re: CVS commit: src/sys/sys

On 23.02.2017 08:32, Paul Goyette wrote: > On Thu, 23 Feb 2017, Kamil Rytarowski wrote: > >> I'm evaluating it from the osabi (pkgsrc term) point of view. I'm >> targeting LLDB for 7.99.62+. If the kernel bump approach is reserved for >> loadable kernel modules, I wi

Re: CVS commit: src/sys/sys

On 23.02.2017 07:23, Robert Elz wrote: > Date:Thu, 23 Feb 2017 05:29:41 + > From:Martin Husemann > Message-ID: <20170223052941.ga29...@homeworld.netbsd.org> > > | Does this kind of change really require a version bump? > > That one didn't,

Locking in cpu_lwp_free()

I've noted that cpu_lwp_free in the current design must not sleep: src/src/sys/kern/kern_lwp.c:1138 /* * We can no longer block. At this point, lwp_free() may already * be gunning for us. On a multi-CPU system, we may be off p_lwps. * * Free MD LWP

Re: LWP resume and suspend ptrace(2) API

On 11.02.2017 17:18, Christos Zoulas wrote: > In article <897028fd-f18a-9ec4-bd5f-3930f40dc...@gmx.com>, > Kamil Rytarowski <n...@gmx.com> wrote: >> >> There is one nit... this code (at least to my tests) cannot unstop a >> thread that was created by a t

Re: LWP resume and suspend ptrace(2) API

On 11.02.2017 04:15, Christos Zoulas wrote: > On Feb 11, 12:49am, krytarow...@gmail.com (Kamil Rytarowski) wrote: > -- Subject: LWP resume and suspend ptrace(2) API > > | I'm proposing an API to restore the functionality to resume or suspend a > | specified thread

LWP resume and suspend ptrace(2) API

I'm proposing an API to restore the functionality to resume or suspend a specified thread from execution. This interface was implemented in the past in user-space inside pthread(3) with the M:N thread model (with help from removed pthread_dbg).

PT_[GS]ET_SIGINFO in ptrace(2)

The current implementation of ptrace(2) has missing interface to retrieve and fake a value of siginfo_t of a signal that was interjected by a tracer. The former is required to help to determine exact event that happened in the code and the latter to programmatically fake routed signal to tracee in

Re: ptrace(2) interface for hardware watchpoints (breakpoints)

On 15.12.2016 19:30, Andrew Cagney wrote: > > On 13 December 2016 at 12:16, Kamil Rytarowski <n...@gmx.com > <mailto:n...@gmx.com>> wrote: > > >> 5. Do not allow to mix PT_STEP and hardware watchpoint, in case of > >> single-stepping the co

Re: ptrace(2) interface for hardware watchpoints (breakpoints)

On 15.12.2016 18:45, Andrew Cagney wrote: > [see end] Please see inline. > > On 13 December 2016 at 12:16, Kamil Rytarowski <n...@gmx.com > <mailto:n...@gmx.com>> wrote: > > On 13.12.2016 04:12, Valery Ushakov wrote: > > On Tue, Dec 13, 2016 at 02

Re: ptrace(2) interface for hardware watchpoints (breakpoints)

Hello, Please see inline, I tried to refer to other questions offlist. On 15.12.2016 16:42, Valery Ushakov wrote: > Again, you don't provide any details. What extra logic? Also, what > are these few dozens of instructions you are talking about? I.e. what > is that extra work you have to do

Re: ptrace(2) interface for hardware watchpoints (breakpoints)

On 15.12.2016 19:45, Andrew Cagney wrote: > > > On 15 December 2016 at 13:22, Eduardo Horvath > wrote: > > > On Thu, 15 Dec 2016, Andrew Cagney wrote: > > > Might a better strategy be to first get the registers exposed, and > then, if >

Re: ptrace(2) interface for hardware watchpoints (breakpoints)

On 13.12.2016 04:12, Valery Ushakov wrote: > On Tue, Dec 13, 2016 at 02:04:36 +0100, Kamil Rytarowski wrote: > >> The design is as follows: >> >> 1. Accessors through: >> - PT_WRITE_WATCHPOINT - write new watchpoint's state (set, unset, ...), >> - PT_READ_W

ptrace(2) interface for hardware watchpoints (breakpoints)

I've prepared interface for hardware watchpoints: http://netbsd.org/~kamil/patch-00023-ptrace-watchpoints.txt For the purpose of this task I propose to call monitoring operations of data as "watchpoints" and monitoring of instruction's executaion as "breakpoints". However this interface is

Re: ptrace(2) thoughts and design

On 26.11.2016 04:31, Kamil Rytarowski wrote: > On 22.11.2016 07:05, Kamil Rytarowski wrote: >> >> On 21.11.2016 05:23, Kamil Rytarowski wrote: >> [...] >>> My plan for the coming days: >>> >>> A. Add introductory man-pages for pthread_dbg, currently

Re: ptrace(2) thoughts and design

On 22.11.2016 07:05, Kamil Rytarowski wrote: > > On 21.11.2016 05:23, Kamil Rytarowski wrote: > [...] >> My plan for the coming days: >> >> A. Add introductory man-pages for pthread_dbg, currently just for the >> used functions in the existing ATF tests, as oth

Re: ptrace(2) thoughts and design

On 21.11.2016 05:23, Kamil Rytarowski wrote: [...] > My plan for the coming days: > > A. Add introductory man-pages for pthread_dbg, currently just for the > used functions in the existing ATF tests, as other interfaces might be > altered later... or just dropped as unneeded. Thi

Re: LLGS for Free/NetBSD (was: Re: [PATCH] D25756: FreeBSD ARM support for software single step.)

On 24.10.2016 20:38, Ed Maste wrote: > On 24 October 2016 at 06:26, Pavel Labath wrote: >> >> It's not my place to tell you how to work, but I'd recommend a >> different approach to this. If you base your work on the current >> FreeBSD in-process plugin, then when you get

Re: Generic crc32c support in kernel?

On 13.08.2016 23:17, Thor Lancelot Simon wrote: > On Fri, Aug 12, 2016 at 07:37:50PM +, paul_kon...@dell.com wrote: >> >> It seems sensible. It could be done by a common CRC routine that takes a >> table pointer argument, then the two specific routines are just wrappers. >> > > It would

Re: FWIW: sysrestrict

On 23.07.2016 10:36, Maxime Villard wrote: > Eight months ago, I shared with a few developers the code for a kernel > interface [1] that can disable syscalls in user processes. > > The idea is the following: a syscall bitmap is embedded into the ELF binary > itself (in a note section, like

Re: Audio - In kernel audio mixing

On 15.05.2016 22:23, Timo Buhrmester wrote: >> I believe that the vaudio approach is better and wanted to start a >> discussion >> about in kernel-mixing and hopefully which approach (if any) should be >> included in NetBSD in future. > A third option would be taking OpenBSD's sndiod (which we

Re: Improvements in amd64

On 13.05.2016 12:53, Maxime Villard wrote: > I've committed several improvements in amd64 these last days. > Thank you for working on it! One question, have you got plans for W^X stacks? I'm asking because I still find trampolines/nested functions useful.

Re: Revamping directory structure of acpica

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 22.10.2015 03:04, Kamil Rytarowski wrote: > I request to synchronize our in-tree directory structure with > upstream acpica. > > At the moment we are moving files and directories around, it makes > harder to upstream ou

Revamping directory structure of acpica

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I request to synchronize our in-tree directory structure with upstream acpica. At the moment we are moving files and directories around, it makes harder to upstream our local patches or compare our version with the upstream one. I know well the

Re: New sysctl entry: proc.PID.realpath

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07.09.2015 03:50, Kamil Rytarowski wrote: > I'm proposing a new sysctl(7) entry: proc.PID.realpath. > > It's modeled after FreeBSD's kern.proc.pathname [1]. > For the reference, the missing sysctl was implemented by Chri

Re: Preproc condition for GCC 2.x

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 18.09.2015 00:53, Michael McConville wrote: > Joerg Sonnenberger wrote: >> On Mon, Sep 14, 2015 at 11:15:34PM -0400, Michael McConville >> wrote: >>> I suspect that this preproc condition isn't necessary anymore? >>> It's in sys/sys/device.h:246.

Re: New sysctl entry: proc.PID.realpath

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07.09.2015 17:58, Jean-Yves Migeon wrote: > Hello there, > > Le 2015-09-07 12:24, Kamil Rytarowski a écrit : >> I'm here to get the support for it. At the moment it (cache nits) >> exceeds my comprehension too. >>

Re: New sysctl entry: proc.PID.realpath

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Thank you for your insight! On 07.09.2015 13:32, Robert Elz wrote: > Date:Mon, 07 Sep 2015 12:24:58 +0200 From: Kamil > Rytarowski <n...@gmx.com> Message-ID: <55ed65fa.1000...@gmx.com> > > | I'm

Re: New sysctl entry: proc.PID.realpath

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07.09.2015 10:47, Stephan wrote: > Wasn´t this the same as with RPATH and the name cache? > > 2015-09-07 9:23 GMT+02:00 Martin Husemann <mar...@duskware.de>: >> On Mon, Sep 07, 2015 at 03:50:21AM +0200, Kamil Rytarowski >

New sysctl entry: proc.PID.realpath

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I'm proposing a new sysctl(7) entry: proc.PID.realpath. It's modeled after FreeBSD's kern.proc.pathname [1]. $ sysctl proc.201.realpath proc.201.realpath = /usr/pkg/bin/cscope $ sysctl proc.1.realpath sysctl: proc.1.realpath: Operation not

Re: Interrupt flow in the NetBSD kernel

On 22.06.2015 19:07, David Young wrote: On Sun, Jun 21, 2015 at 08:01:47AM -0700, Matt Thomas wrote: On Jun 21, 2015, at 7:30 AM, Kamil Rytarowski n...@gmx.com wrote: I have got few questions regarding the interrupt flow in the kernel. Please tell whether my understanding is correct. You

Re: New manpage: locking(9)

On 22.06.2015 18:43, Thor Lancelot Simon wrote: On Sat, Jun 20, 2015 at 03:18:48AM +0200, Kamil Rytarowski wrote: I see no reason to capitulate and drop the original naming, refreshed for the current kernel design in favor of some invented linuxism. You're going to cause massive confusion

Interrupt flow in the NetBSD kernel

I have got few questions regarding the interrupt flow in the kernel. Please tell whether my understanding is correct. There are software and hardware interrupts. Part of the hardware interrupts are maskable with the spl(9) levels. Some are unmaskable and must be handled unconditionally, like the

Re: Interrupt flow in the NetBSD kernel

On 21.06.2015 17:01, Matt Thomas wrote: On Jun 21, 2015, at 7:30 AM, Kamil Rytarowski n...@gmx.com wrote: I have got few questions regarding the interrupt flow in the kernel. Please tell whether my understanding is correct. You are confusing interrupts with exceptions. Interrupts

Re: New manpage: locking(9)

On 19.06.2015 01:06, Paul Goyette wrote: Great to have this. I've attached a diff file with some minor wording/grammar changes. Thank you. When I will make progress in my research I will drop for review new version. I will add notes about the halves anyway, as I can learn from it in the

Re: New manpage: locking(9)

On 18.06.2015 22:33, Christos Zoulas wrote: In article trinity-286f8fb9-ca13-44b1-98d1-8563499c99d4-1434647933661@3capp-mailcom-bs15, Kamil Rytarowski n...@gmx.com wrote: -=-=-=-=-=- I'm attaching a proposition of locking(9). It was inspired by: http://leaf.dragonflybsd.org/cgi/web-man

New manpage: locking(9)

!.\ $NetBSD$ .\ .\ Copyright (c) 2015 The NetBSD Foundation, Inc. .\ All rights reserved. .\ .\ This code is derived from software contributed to The NetBSD Foundation .\ by Kamil Rytarowski. .\ .\ Redistribution and use in source and binary forms, with or without .\ modification, are permitted

Re: New manpage: locking(9)

reference to pserialize(9). .\ $NetBSD$ .\ .\ Copyright (c) 2015 The NetBSD Foundation, Inc. .\ All rights reserved. .\ .\ This code is derived from software contributed to The NetBSD Foundation .\ by Kamil Rytarowski. .\ .\ Redistribution and use in source and binary forms, with or without

Re: Removing ARCNET stuffs

Antti Kantee wrote: On 31/05/15 06:05, matthew green wrote: hi Andrew! :) Who is appalled to discover that pc532 support has been removed! In addition to toolchain support, the hardware was near-extinct at the time of removal. Now, the hardware is no longer near-extinct:

Re: Removing ARCNET stuffs

Johnny Billquist On 2015-05-28 21:19, Tom Ivar Helbekkmo wrote: paul_kon...@dell.com writes: And DECnet nodes exist around the Internet; the “Hobbyist DECnet” group (“hecnet”) is the main focus of that activity as far as I know. ...and while I'm sure Johnny Billquist can supply more

Re: (patch) Improved documentation and examples of dynamic modules

Joerg Sonnenberger wrote: On Wed, May 13, 2015 at 01:52:05PM +0200, Kamil Rytarowski wrote: A FreeBSD developer studying our examples told me that we traditionally use u_int in place of unsigned [int] - calling the usage of 'unsigned' a linuxism. I have no opinions on it. How

Re: (patch) Improved documentation and examples of dynamic modules

Paul Goyette wrote: I have added the EXAMPLES sections. Thank you! If it will be pulled for -7 then please change: first appeared in NetBSD 8.0 to 7.0 in src/sys/modules/examples/README.

Re: (patch) Improved documentation and examples of dynamic modules

and Mindaugas Rasiukevicius. + + This document and additional modules (hello, happy and ping, hellolua) + first appeared in NetBSD 8.0 and they were written by Kamil Rytarowski. + +AUTHORS + This document was written by Kamil Rytarowski. Index: share/examples/sys/kmodule/happy/Makefile

Re: (patch) Improved documentation and examples of dynamic modules

Greg Troxel wrote: Kamil Rytarowski n...@gmx.com writes: Thank you Greg for your reply! Paul Goyette wrote: The happy module makes a claim that 4 digit numbers cannot cycle, and uses a cache[] table for all numbers below 1000. Can you please provide a reference to back up

Re: (patch) Improved documentation and examples of dynamic modules

Greg Troxel wrote: Kamil Rytarowski n...@gmx.com writes: Also, happy doesn't seem like a useful name; examples should have names that suggest the kinds of things they do with respect to the module system, to guide people choosing which ones to read. Well, I like /dev/happy for Happy

Re: (patch) Improved documentation and examples of dynamic modules

Paul Goyette wrote: OK, I looked at all of the examples, except for the lua one (I am lua-clueless). Everything looks OK to me, and I don't see any reason not to commit these. Please try to follow the code, it should illuminate you. If it's too difficult it should be corrected. I do,

Re: (patch) Improved documentation and examples of dynamic modules

Paul Goyette wrote: To: Kamil Rytarowski n...@gmx.com Cc: tech-kern@netbsd.org Subject: Re: (patch) Improved documentation and examples of dynamic modules I'd like to suggest that perhaps the example modules should belong in /usr/share/examples/ or similar? Looks saner. My motivation

(patch) Improved documentation and examples of dynamic modules

in NetBSD 8.0 and they were written by Kamil Rytarowski. + +AUTHORS + This document was written by Kamil Rytarowski. Index: sys/modules/examples/happy/Makefile === RCS file: sys/modules/examples/happy/Makefile diff -N sys/modules

Dynamic modules

I have got a few questions. 1. luapmf and luasystm src/sys/modules/luapmf/luapmf.c src/sys/modules/luasystm/luasystm.c These modules are empty for the !_MODULE build. Why? Can we make them available for the builtin mode. 2. luactl(8) $ sudo luactl help usage: luactl [-cq] luactl [-cq]

Re: Dynamic modules

Sent: Monday, May 04, 2015 at 11:39 AM From: Paul Goyette p...@vps1.whooppee.com To: Kamil Rytarowski n...@gmx.com Cc: tech-kern@netbsd.org Subject: Re: Dynamic modules On Mon, 4 May 2015, Kamil Rytarowski wrote: 3. Is it possible to automatically create a device file in /dev from

Re: Note entry types (core dumps)

Sent: Tuesday, April 28, 2015 at 12:13 PM From: Joerg Sonnenberger jo...@britannica.bec.de To: tech-kern@netbsd.org Subject: Re: Note entry types (core dumps) On Tue, Apr 28, 2015 at 01:45:13PM +0200, Kamil Rytarowski wrote: From what I can see these numbers are standardized across

Note entry types (core dumps)

Hello, What's the status of the note entry types in core dumps in NetBSD? They are extra notes saved during the memory dumping in additional section. mostly dumping content of structures. Just to list their types: #define NT_PRSTATUS 1 /* prstatus_t sys/old_procfs.h */ #define

Re: Removal of compat-FreeBSD

Greg Troxel wrote: Maxime Villard m...@m00nbsd.net writes: Apparently, compat-FreeBSD is needed by tw_cli users. Therefore I think I will just disable it by default in the GENERIC kernels, unless anyone disagrees. Our norms for significant changes are more or less about consensus or

Re: Removal of compat-FreeBSD

Maxime Villard wrote: Hi, I intend to remove the compat-FreeBSD support from the system. Please don't do it.

Tru64 AdvFS porting to NetBSD - 4. status 2014-12-25

Merry Christmas! The last month I used to... clean up and merge improvements with upstream NetBSD. My intention was not to just propose plain new code import, but give a reference patch and try to research a bit a possible improvement to the existing solution. In particular, I pay attention

sys/clock.h finalization

Hello, Please let finalize src/sys/sys/clock.h: 1. Please review and add man page to src/share/man/man9 Thomas K. is responsible for man pages according to src/doc/RESPONSIBLE 2. src/tools/compat/dev/clock_subr.h defines: /* Some handy constants. */ #define SECDAY (24 * 60 * 60)

Re: Reuse strtonum(3) and reallocarray(3) from OpenBSD

Alan Barrett wrote: To: tech-userle...@netbsd.org, tech-kern@netbsd.org Subject: Re: Reuse strtonum(3) and reallocarray(3) from OpenBSD On Sat, 29 Nov 2014, Kamil Rytarowski wrote: My proposition is to add a new header in src/sys/sys/overflow.h (/usr/include/sys/overflow.h

Re: shipping processes between ttys

Hello, I used to use reptyr on RPI with ArchLinux and it worked well. There were two caveats: - processes sleeping in background, - portability - it used to work only on 80x86, amd64 and ARM. I loved it as it was a way to capture a long running process and put it to a screen session. I'm not

Re: link-set

From: Masao Uebayashi This is what I've learned about link-set. TL;DR - link-set is fine except already unused sections are exposed after final link [...] Hello Masao, Thank you for your research! Maybe irrelevant here, but with you work could we consider having room for possible

Re: kernel constructor

From David Holland Please don't do that. Nothing good can come of it - you are asking for a thousand weird problems where undisclosed ordering dependencies silently manifest as strange bugs. Furthermore, the compiler can and probably will assume that constructor functions get called before

Re: kernel constructor

From: Masao Uebayashi The biggest problem of constructors (and indirect function call in general), I am aware of, is, static code analysis (code reading, tag jump, ...) becomes difficult (or impossible). Limited static code analysis is not a bigger problem then a broken machine at boot

Re: Tru64 AdvFS porting to NetBSD - 2. status 2014-10-11

Hello, Are you sure a new dtrace provider would not be the way to go? Yes. I believe that internal performance tracing and tracking locks is misdesign (also not very portable). I'm not familiar with DTrace, more with Linux tools (perf, valgrind) and my general plan was to debug it with

Tru64 AdvFS porting to NetBSD - 2. status 2014-10-11

Hello, This is the second status [1] of porting AdvFS to NetBSD. Thank you for your motivation support, including mails from outside the NetBSD world. 1. What is done - Moved AdvFS files from src/sys/fs/msfs to src/sys/external/gpl2/msfs and updated the build machinery - Picked missing

Re: Unification of common date/time macros

Hello, For your interest there are already patches against current: http://mail-index.netbsd.org/netbsd-bugs/2014/10/08/msg038523.html Best regards,

Re: Unification of common date/time macros

Hello, Good point with reducing the (U)L modifiers, also reducing possible side-effects of 16-bit int, so going for 86400 explicitly is a good idea. I've already proposed patches with this bug-report: http://mail-index.netbsd.org/netbsd-bugs/2014/09/16/msg038315.html My idea was to extract

Re: Tru64 AdvFS porting to NetBSD - 1. status 2014-09-17

Hello, Thank you for your feedback. I will put the moving directories around onto my TODO stack. Please let me do it after resolving thousands of lines of compilation errors (just the kernel-part). I will go for a 'msfs' external name. When I will be done with making it buildable then I will

<    1   2   3   4