linux-kernel - Re: [PATCH 7/8 RESEND] staging: dgap: introduce dgap_cleanup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAHb8M2BOdRXeHXTaWbJgWyo3C+8LRHRGnMyoDD0rwMJD89TqWQ@mail.gmail.com>
Date:	Thu, 17 Jul 2014 08:59:25 +0900
From:	DaeSeok Youn <daeseok.youn@...il.com>
To:	Mark Hounschell <markh@...pro.net>
Cc:	Greg KH <gregkh@...uxfoundation.org>,
	Lidza Louina <lidza.louina@...il.com>,
	devel <devel@...verdev.osuosl.org>,
	driverdev-devel@...uxdriverproject.org,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Dan Carpenter <dan.carpenter@...cle.com>
Subject: Re: [PATCH 7/8 RESEND] staging: dgap: introduce dgap_cleanup_nodes()

Hi, Mark

Thanks for reply.

2014-07-16 21:39 GMT+09:00 Mark Hounschell <markh@...pro.net>:
> On 07/15/2014 11:30 AM, Greg KH wrote:
>>
>> On Tue, Jul 15, 2014 at 06:14:25PM +0900, Daeseok Youn wrote:
>>>
>>> When a configration file is parsed with dgap_parsefile(),
>>> makes nodes for saving configrations for board.
>>
>>
>> configuration files should not be parsed in the kernel at all.  That
>> logic should be removed as it should not be needed.
>>
>> Mark, can you verify that this is not needed with your hardware anymore?
>>
>
> As far as I can see it is still needed. If no config file, no devices are
> created and configured. I had planned to remove that code such that all the
> different cards supported are still supported. Even though I only have 2
> different types of cards. I Just haven't got to it yet. I realize
> "configuration files should not be parsed in the kernel" and I'm certainly
> not going to argue that. But the way it is, it allows user land to define
> board order and even device node names (additional links to the actual
> device). No matter where boards are installed and found by the kernel, you
> have persistent naming.  I guess all that can be done with udev (well, sort
> of anyway).
>
> There are also options in the config file that should be passed in as module
> parameters
> and I planned to do that part before messing with the config file code.
>
> We also have this "DIGI_EXPANDERS_SUPPORTED" thingy. I have none of these
> cards. These cards interrogate the expander to find out how many ports there
> are. Then configure accordingly. Should we just remove all that code and NOT
> support expanders since we don't currently have the hardware to test?
>
> I will update from your current git tree and test this week. I've been
> swamped lately and unable to do much. I thought I'd be available to do some
> more work but things come up as you know.
It need to have this patch when you start to test dgap module. This patch may be
cleaned up memory which are allocated in dgap_parse() when dgap fails
to init or unloads.

And I will send this patch again.

Thanks.
Daeseok Youn.
>
> Regards
> Mark
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/