dm: lookup devices by path with name_to_dev_t
in [Kernel]
|
Prev: [16/39] [S390] dasd: fix race between tasklet and dasd_sleep_on
Next: [12/39] mmc: atmel-mci: remove data error interrupt after xfer
From: Mike Snitzer on 24 May 2010 19:40 On Mon, May 24 2010 at 12:35pm -0400, Will Drewry <wad(a)chromium.org> wrote: > On Mon, May 24, 2010 at 10:07 AM, Alasdair G Kergon <agk(a)redhat.com> wrote: > > On Mon, May 24, 2010 at 09:44:07AM -0500, Will Drewry wrote: > >> fwiw, the only reason for the copy was because |path| is a > >> const in the function but not when passed to name_to_dev_t. > >> I wasn't sure what the preferred practice was so I just duped > >> the data needed. > > > > Well check that it is treated as 'const' and send a separate patch to > > the maintainer to add const, perhaps? �If it isn't const (why would > > that be?), then yes we'd need to copy it. > > I'll cross-check the code again and send a patch out if it looks like > it is const-safe. Also, it would see that name_to_dev_t is EXPORT_SYMBOL? Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Mike Snitzer on 24 May 2010 20:00 On Mon, May 24 2010 at 7:35pm -0400, Mike Snitzer <snitzer(a)redhat.com> wrote: > On Mon, May 24 2010 at 12:35pm -0400, > Will Drewry <wad(a)chromium.org> wrote: > > > On Mon, May 24, 2010 at 10:07 AM, Alasdair G Kergon <agk(a)redhat.com> wrote: > > > On Mon, May 24, 2010 at 09:44:07AM -0500, Will Drewry wrote: > > >> fwiw, the only reason for the copy was because |path| is a > > >> const in the function but not when passed to name_to_dev_t. > > >> I wasn't sure what the preferred practice was so I just duped > > >> the data needed. > > > > > > Well check that it is treated as 'const' and send a separate patch to > > > the maintainer to add const, perhaps? �If it isn't const (why would > > > that be?), then yes we'd need to copy it. > > > > I'll cross-check the code again and send a patch out if it looks like > > it is const-safe. > > Also, it would see that name_to_dev_t is EXPORT_SYMBOL? Bleh, I typed that way too quick: Also, it would seem that name_to_dev_t is _not_ EXPORT_SYMBOL? Regards, Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Will Drewry on 25 May 2010 12:00
On Mon, May 24, 2010 at 6:55 PM, Mike Snitzer <snitzer(a)redhat.com> wrote: > On Mon, May 24 2010 at �7:35pm -0400, > Mike Snitzer <snitzer(a)redhat.com> wrote: > >> On Mon, May 24 2010 at 12:35pm -0400, >> Will Drewry <wad(a)chromium.org> wrote: >> >> > On Mon, May 24, 2010 at 10:07 AM, Alasdair G Kergon <agk(a)redhat.com> wrote: >> > > On Mon, May 24, 2010 at 09:44:07AM -0500, Will Drewry wrote: >> > >> fwiw, the only reason for the copy was because |path| is a >> > >> const in the function but not when passed to name_to_dev_t. >> > >> I wasn't sure what the preferred practice was so I just duped >> > >> the data needed. >> > > >> > > Well check that it is treated as 'const' and send a separate patch to >> > > the maintainer to add const, perhaps? �If it isn't const (why would >> > > that be?), then yes we'd need to copy it. >> > >> > I'll cross-check the code again and send a patch out if it looks like >> > it is const-safe. >> >> Also, it would see that name_to_dev_t is EXPORT_SYMBOL? > > Bleh, I typed that way too quick: > Also, it would seem that name_to_dev_t is _not_ EXPORT_SYMBOL? I've just mailed out a patch for each issue: - const char *: https://patchwork.kernel.org/patch/102228/ - export_symbol: https://patchwork.kernel.org/patch/102229/ Cheers! will -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |