Linus Torvalds <torva...@linux-foundation.org> wrote: > ... > So the end result is that we run that "filechk_x509_list" script, > compare the output to the old target, and update the target iff it is > different. That would seem to be exactly what we want.
Yep. > That said, as mentioned, the whole "X509_CERTIFICATES" thing is > unstable, and ends up being "./signing_key.x509" or "signing_key.x509" > depending on whether that file existed or not. That needs fixing, so > that we get stable output. So some filtering required. Yeah, the stability thing is a bit of an irritation. X509_CERTIFICATES might also include "$(srcdir)/signing_key.x509". This is one of the things that has given me difficulties because the source and build trees are sometimes the same and sometimes not (and then throw in a symlink somewhere in the path...). I was trying to use $(realpath ...) to deal with this - but that doesn't work if the path doesn't point to an extant file:-/ Does it make sense to produce an error if the source and build trees are not coincident and we see an x509 cert of the same filename cropping up in both? Also X509_CERTIFICATES might hold other certs - though these shouldn't really be seen in the build dir. I wonder if we should enforce that to make life easier. David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
