February 2014 - kernelnewbies@kernelnewbies.org

How to get the inode - no path_lookup
by Rishi Agrawal Sept. 17, 2015

Sept. 17, 2015

Hi All, I had a module which used the path_lookup function to print the details of any file's inode. I now want to rewrite that module in order to show some juniors how to write some code in kernel. I am using 3.4.6 kernel, I tried finding out path_lookup but google showed that it has been removed. I tried the following code then which did not work . . . dentry = kern_path_create(AT_FDCWD, filename, &path, 1); if (IS_ERR(dentry)) { printk("Failed to obtain the dentry"); return; } its not returning dentry I again tried after seeing the implementation of vfs_stat function user_path_at(AT_FDCWD, filename, lookup_flags, &path); but this also fails. I am using a proc interface to pass the filename, and copying the filename into a kernel buffer. How can I get a copy of vfs inode for a file name. -- Regards, Rishi Agrawal

4 8

Re: MPC8641 based custom board kernel Bug
by Ashish Khetan May 2, 2014

May 2, 2014

i tried to dig more inside mpic_alloc fails. the function of_find_matching_node calls inside from mpic_alloc() should return the node at which pic is connected but it returns NULL. but why? In device tree i am using the following.. may be it will helpful. /dts-v1/; / { model = "MPC8641HPCN"; compatible = "fsl,mpc8641hpcn"; #address-cells = <0x1>; #size-cells = <0x1>; aliases { ethernet0 = "/soc8641@f8000000/ethernet@24000"; ethernet1 = "/soc8641@f8000000/ethernet@25000"; ethernet2 = "/soc8641@f8000000/ethernet@26000"; ethernet3 = "/soc8641@f8000000/ethernet@27000"; serial0 = "/soc8641@f8000000/serial@4500"; }; cpus { #address-cells = <0x1>; #size-cells = <0x0>; PowerPC,8641@0 { device_type = "cpu"; reg = <0x0>; d-cache-line-size = <0x20>; i-cache-line-size = <0x20>; d-cache-size = <0x8000>; i-cache-size = <0x8000>; timebase-frequency = <0x0>; bus-frequency = <0x0>; clock-frequency = <0x0>; }; }; memory { device_type = "memory"; reg = <0x0 0x20000000>; }; localbus@f8005000 { #address-cells = <0x2>; #size-cells = <0x1>; compatible = "fsl,mpc8641-localbus", "simple-bus"; reg = <0xf8005000 0x1000>; interrupts = <0x13 0x2>; interrupt-parent = <0x1>; ranges = <0x0 0x0 0xff000000 0x1000000>; flash@0,0 { compatible = "cfi-flash"; reg = <0x0 0x0 0x800000>; bank-width = <0x2>; device-width = <0x2>; #address-cells = <0x1>; #size-cells = <0x1>; }; }; soc8641@f8000000 { #address-cells = <0x1>; #size-cells = <0x1>; device_type = "soc"; compatible = "simple-bus"; ranges = <0x0 0xf8000000 0x100000>; bus-frequency = <0x0>; mcm-law@0 { compatible = "fsl,mcm-law"; reg = <0x0 0x1000>; fsl,num-laws = <0xa>; }; mcm@1000 { compatible = "fsl,mpc8641-mcm", "fsl,mcm"; reg = <0x1000 0x1000>; interrupts = <0x11 0x2>; interrupt-parent = <0x1>; }; dma@21300 { #address-cells = <0x1>; #size-cells = <0x1>; compatible = "fsl,mpc8641-dma", "fsl,eloplus-dma"; reg = <0x21300 0x4>; ranges = <0x0 0x21100 0x200>; cell-index = <0x0>; dma-channel@0 { compatible = "fsl,mpc8641-dma-channel", "fsl,eloplus-dma-channel"; reg = <0x0 0x80>; cell-index = <0x0>; interrupt-parent = <0x1>; interrupts = <0x14 0x2>; }; dma-channel@80 { compatible = "fsl,mpc8641-dma-channel", "fsl,eloplus-dma-channel"; reg = <0x80 0x80>; cell-index = <0x1>; interrupt-parent = <0x1>; interrupts = <0x15 0x2>; }; dma-channel@100 { compatible = "fsl,mpc8641-dma-channel", "fsl,eloplus-dma-channel"; reg = <0x100 0x80>; cell-index = <0x2>; interrupt-parent = <0x1>; interrupts = <0x16 0x2>; }; dma-channel@180 { compatible = "fsl,mpc8641-dma-channel", "fsl,eloplus-dma-channel"; reg = <0x180 0x80>; cell-index = <0x3>; interrupt-parent = <0x1>; interrupts = <0x17 0x2>; }; }; ethernet@24000 { #address-cells = <0x1>; #size-cells = <0x1>; cell-index = <0x0>; device_type = "network"; model = "TSEC"; compatible = "gianfar"; reg = <0x24000 0x1000>; ranges = <0x0 0x24000 0x1000>; local-mac-address = [00 00 00 00 00 00]; interrupts = <0x1d 0x2 0x1e 0x2 0x22 0x2>; interrupt-parent = <0x1>; tbi-handle = <0x2>; phy-handle = <0x3>; phy-connection-type = "rgmii-id"; mdio@520 { #address-cells = <0x1>; #size-cells = <0x0>; compatible = "fsl,gianfar-mdio"; reg = <0x520 0x20>; ethernet-phy@0 { interrupt-parent = <0x1>; interrupts = <0xa 0x1>; reg = <0x0>; device_type = "ethernet-phy"; linux,phandle = <0x3>; }; ethernet-phy@1 { interrupt-parent = <0x1>; interrupts = <0xa 0x1>; reg = <0x1>; device_type = "ethernet-phy"; linux,phandle = <0x5>; }; ethernet-phy@2 { interrupt-parent = <0x1>; interrupts = <0xa 0x1>; reg = <0x2>; device_type = "ethernet-phy"; linux,phandle = <0x7>; }; ethernet-phy@3 { interrupt-parent = <0x1>; interrupts = <0xa 0x1>; reg = <0x3>; device_type = "ethernet-phy"; linux,phandle = <0x9>; }; tbi-phy@11 { reg = <0x11>; device_type = "tbi-phy"; linux,phandle = <0x2>; }; }; }; ethernet@25000 { #address-cells = <0x1>; #size-cells = <0x1>; cell-index = <0x1>; device_type = "network"; model = "TSEC"; compatible = "gianfar"; reg = <0x25000 0x1000>; ranges = <0x0 0x25000 0x1000>; local-mac-address = [00 00 00 00 00 00]; interrupts = <0x23 0x2 0x24 0x2 0x28 0x2>; interrupt-parent = <0x1>; tbi-handle = <0x4>; phy-handle = <0x5>; phy-connection-type = "rgmii-id"; mdio@520 { #address-cells = <0x1>; #size-cells = <0x0>; compatible = "fsl,gianfar-tbi"; reg = <0x520 0x20>; tbi-phy@11 { reg = <0x11>; device_type = "tbi-phy"; linux,phandle = <0x4>; }; }; }; ethernet@26000 { #address-cells = <0x1>; #size-cells = <0x1>; cell-index = <0x2>; device_type = "network"; model = "TSEC"; compatible = "gianfar"; reg = <0x26000 0x1000>; ranges = <0x0 0x26000 0x1000>; local-mac-address = [00 00 00 00 00 00]; interrupts = <0x1f 0x2 0x20 0x2 0x21 0x2>; interrupt-parent = <0x1>; tbi-handle = <0x6>; phy-handle = <0x7>; phy-connection-type = "rgmii-id"; mdio@520 { #address-cells = <0x1>; #size-cells = <0x0>; compatible = "fsl,gianfar-tbi"; reg = <0x520 0x20>; tbi-phy@11 { reg = <0x11>; device_type = "tbi-phy"; linux,phandle = <0x6>; }; }; }; ethernet@27000 { #address-cells = <0x1>; #size-cells = <0x1>; cell-index = <0x3>; device_type = "network"; model = "TSEC"; compatible = "gianfar"; reg = <0x27000 0x1000>; ranges = <0x0 0x27000 0x1000>; local-mac-address = [00 00 00 00 00 00]; interrupts = <0x25 0x2 0x26 0x2 0x27 0x2>; interrupt-parent = <0x1>; tbi-handle = <0x8>; phy-handle = <0x9>; phy-connection-type = "rgmii-id"; mdio@520 { #address-cells = <0x1>; #size-cells = <0x0>; compatible = "fsl,gianfar-tbi"; reg = <0x520 0x20>; tbi-phy@11 { reg = <0x11>; device_type = "tbi-phy"; linux,phandle = <0x8>; }; }; }; serial@4500 { cell-index = <0x0>; device_type = "serial"; compatible = "ns16550"; reg = <0x4500 0x100>; clock-frequency = <0x0>; interrupts = <0x2a 0x2>; interrupt-parent = <0x1>; }; pic@40000 { interrupt-controller; #address-cells = <0x0>; #interrupt-cells = <0x2>; reg = <0x40000 0x40000>; compatible = "chrp,open-pic"; device_type = "open-pic"; linux,phandle = <0x1>; phandle = <0x1>; }; global-utilities@e0000 { compatible = "fsl,mpc8641-guts"; reg = <0xe0000 0x1000>; fsl,has-rstcr; }; }; chosen { linux,stdout-path = "/soc8641/serial0: serial@4500"; }; }; On Thu, Dec 26, 2013 at 2:37 PM, wyang <w90p710(a)gmail.com> wrote: > On 12/26/2013 01:09 PM, Ashish Khetan wrote: > > Hi, > I was trying to port Linux-3.12 for MPC8641 based custom designed board > for evaluation purpose. I have been facing a kernel bug at mpic > initialization. Is somebody have faced this kind of bugs or can give me any > pointer for further steps how to solve kernel bugs will be really helpful. > here is the snapshot for the bug that may be helpful to address the bug. > Using MPC86xx HPCN machine description > Total memory = 512MB; using 1024kB for hash table (at cff00000) > Linux version 3.12.0 (ashish@ashish-VirtualBox) (gcc version 4.7.2 (GCC) > ) #2 We > d Dec 25 16:04:36 IST 2013 > Found initrd at 0xde975000:0xdfec428a > bootconsole [udbg0] enabled > setup_arch: bootmem > mpc86xx_hpcn_setup_arch() > MPC86xx HPCN board from Freescale Semiconductor > arch: exit > Zone ranges: > DMA [mem 0x00000000-0x1fffffff] > Normal empty > HighMem empty > Movable zone start for each node > Early memory node ranges > node 0: [mem 0x00000000-0x1fffffff] > Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048 > Kernel command line: root=/dev/ram0 rw rootfs console=ttyS0,115200 > PID hash table entries: 2048 (order: 1, 8192 bytes) > Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) > Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) > Sorting __ex_table... > Memory: 424980K/524288K available (4172K kernel code, 208K rwdata, 1304K > rodata, > 196K init, 149K bss, 99308K reserved, 0K highmem) > Kernel virtual memory layout: > * 0xfffcf000..0xfffff000 : fixmap > * 0xff800000..0xffc00000 : highmem PTEs > * 0xff7fe000..0xff800000 : early ioremap > * 0xe1000000..0xff7fe000 : vmalloc & ioremap > SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 > NR_IRQS:512 nr_irqs:512 16 > ------------[ cut here ]------------ > kernel BUG at arch/powerpc/platforms/86xx/pic.c:42! > > > It hints that mpic_alloc() fails. Maybe, you should spend some time > investigating why it fails. :-) > > Thanks > Wei > > Oops: Exception in kernel mode, sig: 5 [#1] > MPC86xx HPCN > Modules linked in: > CPU: 0 PID: 0 Comm: swapper Not tainted 3.12.0 #2 > task: c05903e0 ti: c05b4000 task.ti: c05b4000 > NIP: c0567438 LR: c0567430 CTR: c0567400 > REGS: c05b5ee0 TRAP: 0700 Not tainted (3.12.0) > MSR: 00021032 <ME,IR,DR,RI> CR: 24000042 XER: 20000000 > > GPR00: c0567430 c05b5f90 c05903e0 00000000 c04e4ff8 c051e588 0000008f > 00000002 > GPR08: c042789c 00000001 0000006f 00000000 22000048 bebffffd 11a7b4e5 > 200c8000 > GPR16: ffbeffff ffffffff 00000000 00000024 00000000 1fec56f8 1fec59a7 > 00000000 > GPR24: 00000000 1fff97e8 40000000 1ffcc6a0 c0bff080 c05c2490 c05c2628 > c0585b60 > NIP [c0567438] mpc86xx_init_irq+0x38/0x108 > LR [c0567430] mpc86xx_init_irq+0x30/0x108 > Call Trace: > [c05b5f90] [c0567430] mpc86xx_init_irq+0x30/0x108 (unreliable) > [c05b5fb0] [c0562784] init_IRQ+0x24/0x38 > [c05b5fc0] [c055fde4] start_kernel+0x1bc/0x2ec > [c05b5ff0] [00003444] 0x3444 > Instruction dump: > 3d00c04f 38800000 38a01002 38c00000 38e00100 39088f8c 38600000 90010024 > bfa10014 4bffec35 7c690034 5529d97e <0f090000> 3fa0c04f 4bfff391 38600000 > ---[ end trace 31fd0ba7d8756001 ]--- > > Kernel panic - not syncing: Attempted to kill the idle task! > Rebooting in 180 seconds.. > > > Thanks & Regards > Ashish Khetan > > > _______________________________________________ > Linuxppc-dev mailing listLinuxppc-dev@lists.ozlabs.orghttps://lists.ozlabs.org/listinfo/linuxppc-dev > > >

5 8

RE: Debugging techniques inside kernel
by Anand Arumugam April 9, 2014

April 9, 2014

Try using strace and see if all of the different crashes have the same or similar looking call stack. Here's a link on how to use it in case you didn't know already: http://stackoverflow.com/questions/174942/how-to-use-strace -----Original Message----- From: manty kuma Sent: 7/7/2013 8:06 PM To: Valdis Kletnieks Cc: kernelnewbies(a)kernelnewbies.org Subject: Re: Debugging techniques inside kernel Hi Valdis, Thanks for the info. I have serial logs (using minicom). This is not helping me much as randomly memory is getting crashed and everytime it changes. Even the logs before the crash are varying everytime. On Mon, Jul 8, 2013 at 11:49 AM, <Valdis.Kletnieks(a)vt.edu> wrote: On Mon, 08 Jul 2013 11:22:16 +0900, manty kuma said: > For ex : *CONFIG_SLUB_DEBUG_ON, *CONFIG_DMA_API_DEBUG > I am just told to use these configs and check. Not sure how to use them > effectively. Please share if you are aware of these kind of configs and how > to use them. To have them at one place it would be useful for debugging > beginners like me. Most _DEBUG config options are set-and-forget - you turn them on and there's no further configuration needed. They enable additional code that does additional sanity checking and if it finds a problem, it issues a printk() or a stack dump or similar which shows up in dmesg. If you're chasing memory corruption, it may be useful to use netconsole or a serial console to send out all the printk() output in real time, as often an error will be detected but the system will panic()/crash/hang in a way that your local syslog daemon is unable to write the message to disk. (I'm told that on newer UEFI based systems, you can use pstore in a similar fashion, but have not tried it myself yet).

4 3

simplefs - a ridiculosly simple file system from the scratch
by Sankar P April 1, 2014

April 1, 2014

Hi, For learning purposes, I thought I would implement a filesystem from the scratch. It has reached a state where I can do a 1.0 release. The sources are at: https://github.com/psankar/simplefs The layout is simple. The first (zeroth) block is the superblock and contains information like fs magic, number of inodes, freeblock map etc. The next block is the inode store. Creation of files and directories is supported. Nested directories are supported. A file can grow up to one block only. The data blocks for a directory contain the filename and inode number of its children. For files, it will obviously contain the actual data of the file. There are three rudimentary locks to make sure the accesses are thread safe. The 1.0 version is filled with a lot of TODOs and memory leaks. Also while implementing this, I realized that it is a bad idea to maintain the superblock and the freeblock store together in a block. So I am planning to change the on-disk layout in the next version. Apart from moving the super block to minimize locks, I am planning to implement support for extents in the next version, and journalling in the next-to-next version. The next version will take some time to come, though. But if someone wants to try filesystems from the scratch, I thought it may be useful if I share the link now itself. Also, I take this moment to thank the kernelnewbies list, especially the regular people like Mulyadi Santosa, Valdis Kletnieks, Rajat Sharma, Greg Freemyer etc. Also I would like to thank Neha Naik, Manish Katiyar who helped me with some queries during this particular implementation. I saw that Manish Katiyar has also done a similar from-the-scratch implementation and it motivated me to pursue further. Any feedback on the code is welcome. Although, I want to inform that I plan to change the locking until after I decide on a good on-disk layout for the next version, which will by-design minimize the locking needs, by splitting out freestore from superblock, keep track of children inode in a better way etc. Also I have been resisting the urge to look at ext or any other filesystem's design so as to not skew my thoughts and go with a fresh state of mind and get my own design :) Thanks. -- Sankar P http://psankar.blogspot.com

4 12

how to determine kernel interrupt latency
by loody March 16, 2014

March 16, 2014

hi all: is it possible to determine interrupt latency in kernel with any ftrace or proc? -- Regards,

2 3

Rebuild kernel so complicated?
by 乃宏周 March 14, 2014

March 14, 2014

AFAIK, rebuild the kernel should follow those steps at least: - *copy /boot/system-$(uname -r).map to ${kernel_src}* - *copy /boot/config-$(uname -r) to ${kernel_src}* - *cd ${kernel_src}* - *make menuconfig*, save config(If I don't wanna change anything for test). - *make -j9 bzImage.* - *override /boot/vmlinuz-$(uname -r) with ${kernel_src}/arch/x86/boot/bzImage* Maybe those steps contains some typo or has some different paths. Buts the point is I don't change any features from original setting, I just copy my system.map and config to kernel source's one and rebuild the kernel(should be the same with mine). When I override new kernel and reboot, It just hanged, no any message print out(No Oops, No panics). But if I do those steps with this<http://it.livekn.com/2013/01/compile-kernel.html>, everything goes fine. I just don't know the differences between the standard way and debian's way. Is ubuntu abnormal ?

3 2

mmap giving Permission Denied error
by Ravi Teja March 8, 2014

March 8, 2014

Hello all, I tried mmap'ing to address zero after setting */proc/sys/vm/mmap_min_addr*to * 0*, but mmap is giving Permission Denied error. My C code is as below - #include <stdio.h> #include <stdlib.h> #include <sys/mman.h> int main(void) { int *ptr = NULL; ptr = mmap(0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0); if(ptr == MAP_FAILED) { perror("Error in mapping\n"); exit(1); } printf("After mmap\n"); *ptr = 16; printf("Contents of address 0x%x is :: %d\n",ptr,*ptr); return 0; } Am I doing anything wrong here? Thank you in advance. Regards, Ravi Teja

5 6

Re: [Printing-architecture] Google Summer of Code 2014 - IPP-over-USB printer support - Joint project idea for OpenPrinting and the kernel
by Michael Sweet March 4, 2014

March 4, 2014

Carlos, Any Mac running OS X 10.9 supports IPP USB; note that we have a bunch of pending bug fixes (sorry, can't say when the fixes will be released...) that address issues found in testing with multiple vendors' implementations of IPP USB, but the current 10.9.2 will work with all of the HP printers mentioned below. On Feb 27, 2014, at 2:23 PM, Carlos Rimola <crimola(a)gmail.com> wrote: > Michael, > > Thanks for the comprehensive response to my questions on IPP USB and confirming my assumptions. > > The only remaining question I have for the list at this time is - are there any Hosts, including model, OS and OS version (or other S/W requirements), presently available on the market (or otherwise) which support IPP USB as per the Specification? > > Thanks again, > > Carlos Rimola > > > On Thu, Feb 27, 2014 at 7:37 AM, Michael Sweet <msweet(a)apple.com> wrote: > Carlos, > > On Feb 26, 2014, at 9:33 PM, Carlos Rimola <crimola(a)gmail.com> wrote: >> Hi All, >> >> I have some quick and general questions regarding IPP over USB ("IPP USB" for short). Some are related to Till's proposed project "Google Summer of Code 2014 - IPP-over-USB printer support". Any help and feedback will be greatly welcomed. I should mention that I am in favor of the proposed project for this event. >> >> Assumptions (please confirm or correct): >> >> 1) This first one may be obvious but to be sure - I am assuming that we are referring to IPP USB as defined in the "USB Print Interface Class IPP Protocol Specification Revision 1.0" dated 12/5/2012 and published by USB-IF and authored by HP's Smith Kennedy and Andrew R. Mitchell. I'll refer to it as the "IPP USB Spec". >> > Correct. >> 2) As I understand the IPP USB Spec, there is NO network interface, NOR TCP/IP involved. The Communication Protocol to be used between Host and Device (Printer) is purely HTTP + IPP directly over USB. A place where this is noted is section 6.2 - "HTTP Headers" which states the following: >> >> Since there is NO network interface connection, NO DNS hostnames or IP addresses, and NO TCP port numbers associated with USB connection, the requirements of the HTTP Host field is addressed by requiring that the value of this header MUST be "localhost". >> >> Please correct me if I am wrong on either of these assumptions. >> > > Correct (a port number can be passed by the "client" over USB to allow gateways/proxies to work...) >> Questions: >> >> 1) I know the Spec is already cast in stone but I would like to understand what function HTTP serves and if it is only used for identifying "Host: localhost" and the "/ipp/printer" path? In other words, could pure IPP Requests/Responses and IPP expected format "Print Data" have sufficed? > > While you might get away with that for simple IPP messages, that wouldn't work for document data since IPP by itself has no framing or other niceties - you'd never know when the data ended. > > Also, the HTTP portion is used for the embedded web server, doing firmware updates, and so forth. >> >> 2) Section 3.2 "Interface Set" paragraph 2 states that "All IPP USB capable Print class interfaces provided by a device MUST be functionally equal from an IPP operation or HTTP perspective. In other words, any IPP operation or resource path that is valid over one IPP USB interface MUST be reachable via any and all of the IPP USB interfaces." >> >> Does this imply that, for example, a Request from the host can be sent over one interface (I/F #1) and the response received over a different interface (e.g., I/F #2)? >> > No, each interface is an independent channel to the printer. > > The reason for this requirement is to prevent having an IPP USB endpoint just for printing, and another just for scanning, and so forth. Effectively IPP USB defines an interface protocol that allows arbitrary HTTP and IPP requests to be performed. >> 3) The last question is much simpler but would be helpful to an implementor - what specific printers (manufacturer, line and model) on the market support IPP USB? I have seen references to HP Photosmart and OfficeJet but no model given. Similarly, what Host(s) on the market, including OS and version, support the IPP USB protocol with these Printers? >> > Here is the latest list we have from HP: > > Deskjet 3520 > Envy 120 > Envy 4500 > Envy 5530 > Officejet 3620 > Officejet 4630 > Officejet 7610 > Officejet Pro 276 MFP > Officejet Pro X576 dw > Photosmart 5520 > Photosmart 6520 > Photosmart 7520 > > I know of four other manufacturers that either have shipping products or will soon be shipping - will post here when I can do so publicly... > > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > > _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair

2 1

Reset due to emergency remount r/o
by Priyaranjan Das March 3, 2014

March 3, 2014

Hi All, I am facing an kernel restart due to emergency remount. Could anybody tell me general techniques to go head with the debugging? Below are the logs which are seen during a reboot. [ 425.832395,1] SysRq : Emergency Remount R/O [ 425.876210,1] EXT4-fs (mmcblk0p36): re-mounted. Opts: (null) [ 425.925899,1] EXT4-fs (mmcblk0p33): re-mounted. Opts: (null) [ 425.928731,1] EXT4-fs (mmcblk0p29): re-mounted. Opts: (null) [ 425.955762,1] Emergency Remount complete [ 426.187136,0] Restarting system with command 'bootloader'. [ 426.187327,0] Current task:init(1) Parent task:swapper/0(0) [ 426.187430,0] Going down for restart now Regards, Priyaranjan

7 6

LF GSoC page
by Sima Baymani March 2, 2014

March 2, 2014

Hi Till, I'm guessing you're the author of this http://www.linuxfoundation.org/collaborate/workgroups/gsoc/2014-gsoc-kernel… which points to #kernelnewbies. Right now there are a lot of people coming in and asking for info or help etc. It would be helpful if you could add some more detail there. For example Greg K-H has stated he's the one to ping (or email, according to himself) - that could be something to add. Also, as far as I understand, applicants have to have an idea/suggestion of their own for projects (according to chats by Greg). Could you add information about that as well? Right now everybody else in that channel are more or less clueless, which imo isn't a good first impression for applicants =) BR, Sima

2 3