Re: [Scst-devel] Regarding filp_open usage

[Sietse v. Z. <si...@wi...>]

Neelakantan,

Consider the following. Kernel module opens a file. File happens to be a sql database. Now the kernel should contain all the interpreation necessary to parse the sql data in the file. This means the kernel module should be aware of all the tables, columns etc. This will make the code kernel module quite big and likely dupliacte of userspace interpretation by library. Also when the layout of the file changes (table added etc) a reboot, or reload of the module is necessary, since the kernel module code will change too. In case of interpretation by library it would be as simple as to replace the lib and reread the file.

Hence it is not recommended to do such things in kernel space. But in some cases it is a necessity as kernel will allow for an x factor better performance, like scst io to a file backing a vdisk device.\

-Sietse

________________________________________
From: Neelakantan Kannappa (nkannapp) <Nee...@qu...>
Sent: Monday, October 23, 2017 15:29
To: Sietse van Zanen; scs...@li...
Subject: RE: [Scst-devel] Regarding filp_open usage

Sietse,

Thanks for you clarification.

Configuration can be handled through module parameters, sys-fs (like scst does) or through procfs.

Could you please elaborate with an example about the issues of interpretation of file-content/configuration-data by the kernel module?

Thanks,
Neelakantan K.

-----Original Message-----
From: Sietse van Zanen [mailto:si...@wi...]
Sent: Monday, October 23, 2017 6:50 PM
To: Neelakantan Kannappa (nkannapp) <Nee...@qu...>; scs...@li...
Subject: Re: [Scst-devel] Regarding filp_open usage


Hi Neelakanan,

That article is 12! years old and pretty much superseeded by the requirement to do certain file access from kernel, mostly for performance and / or security reasons.

Article is still correct about configuration data not supposed to be read by kernel (module) and the issue of interpretation. Both of which do not apply to scst_vdisk, since the files contain no configuration data and interpretation is the most simple possible (raw data). Any interpretation of the data is of course only for the initiator to decide.

-Sietse

________________________________________
From: Neelakantan Kannappa (nkannapp) <Nee...@qu...>
Sent: Monday, October 23, 2017 14:57
To: Sietse van Zanen; scs...@li...
Subject: RE: [Scst-devel] Regarding filp_open usage

http://www.linuxjournal.com/article/8110?page=0,2 and

many pages result from google too discourage file manipulation in Linux kernel.



-----Original Message-----
From: Sietse van Zanen [mailto:si...@wi...]
Sent: Monday, October 23, 2017 6:23 PM
To: Neelakantan Kannappa (nkannapp) <Nee...@qu...>; scs...@li...
Subject: Re: [Scst-devel] Regarding filp_open usage

1. Who says that, and where? I suspect you are missing some context in asking that question.

2. Because accessing from userspace would incur a huge performance penalty.


-Sietse


________________________________
From: Neelakantan Kannappa (nkannapp) <Nee...@qu...>
Sent: Monday, October 23, 2017 11:06
To: scs...@li...
Subject: [Scst-devel] Regarding filp_open usage


Hi,



Many of the kernel developers suggest that opening a file in the kernel land is not good.



Contrary to this SCST device handler for vdisk is using filp_open call.



How is this accepted by the Linux kernel community?





Thanks,

Neelakantan K.